[Distutils] Working toward Linux wheel support

Tue Sep 8 00:16:48 CEST 2015

On Sep 7, 2015 12:51 PM, "Marcus Smith" <qwcode at gmail.com> wrote:
>
> Wes, this isn't about the versioning scheme for Specs or PEPS.
> For *whatever* scheme we have,  my discussion was about how to render all
the "current" versions we support in a Sphinx project.

More or less itertools.product and a sphinx directive for ~CSVW?

Marcus, we could change the subject line.

The objective here, IIUC, is to generate and maintain the expanded set of
packages and their metadata [[[ with the ability to download all/subset of
the package metadata [ without having to execute each and every setup.py [
again ] ] ]]].

Possible subject lines:

* [ ] Add RDFa to pypi and warehouse
* [ ] Add JSONLD to pypi and warehouse
* "PEP ???: Metadata 3.0.1" * "Re: [Python-ideas] Increasing public package
discoverability (was: Adding jsonschema to the standard library)"
  * https://groups.google.com/d/msg/python-ideas/3MRVM6C6bQU/76hWP7bFgiwJ
  * https://groups.google.com/d/msg/python-ideas/3MRVM6C6bQU/VXq3yHcrCxcJ

```
So there is a schema.org/SoftwareApplication (or doap:Project, or seon:)
Resource,
which has

* a unique URI (e.g. http://python.org/pypi/readme)
* JSON metadata extracted from setup.py into pydist.json (setuptools, wheel)
  - [ ] create JSON-LD @context
  - [ ] create mappings to standard schema
    * [ ] http://schema.org/SoftwareApplication
    * [ ] http://schema.org/SoftwareSourceCode

In terms of schema.org, a Django Packages resource has:

* [ ] a unique URI
* [ ] typed features (predicates with ranges)
* [ ] http://schema.org/review
* [ ] http://schema.org/VoteAction
* [ ] http://schema.org/LikeAction
```
There is a matrix of packages that could, should, are uploaded;
which is a subset of a [giant global] graph;
which can be most easily represented in an RDF graph representation format
like RDFa, JSON-LD, CSVW.

* setup.py
* requirements[-test|-docs][-dev][.peep].txt
* tox.ini -- tox grid (+docker = dox)
* Jenkins grid
* --> Pypi (e.g. with twine)

This does something more sequential than itertools.product
w/ a Requirement namedtuple and a RequirementsMap to iterate through (for
generating combinations of requirements-{test,dev,{extras}}:
* https://github.com/westurner/pyleset/blob/57140bcef53/setup.py
* https://github.com/westurner/pyleset/tree/57140bcef53/requirements

> in short, should the current versions we want to publish be distinct
documents or not.
>
> >  The PEP workflow is probably fine
>
> well, if you look up in the thread, a few of us are saying it's not.  It
doesn't distinguish Current Specs vs Proposals very well.

How would you add that metadata to the version string (according to PEP
440)? Semver 3.0 (pbr)

>From http://docs.openstack.org/developer/pbr/semver.html :
    Example: 1.0.0.dev8 < 1.0.0.dev9 < 1.0.0.a1.dev3 < 1.0.0.a1 < 1.0.0.b2
< 1.0.0.c1 < 1.0.0

>
>
> On Mon, Sep 7, 2015 at 9:40 AM, Wes Turner <wes.turner at gmail.com> wrote:
>>
>> MAJOR.MINOR.PATCH[-rev] would be helpful for these  (and other) PEPs.
>>
>> On Sep 7, 2015 10:36 AM, "Marcus Smith" <qwcode at gmail.com> wrote:
>> >
>> > I'm still unclear on whether you'd want A or B:
>> >
>> > A) Different major/minor versions of the spec are different documents
>>
>> From http://semver.org Semantic Versioning 2.0 :
>>
>> ```
>> Given a version number MAJOR.MINOR.PATCH, increment the:
>>
>> - MAJOR version when you make incompatible API changes,
>> - MINOR version when you add functionality in a backwards-compatible
manner, and
>> - PATCH version when you make backwards-compatible bug fixes.
>>
>> Additional labels for pre-release and build metadata are available as
extensions to the MAJOR.MINOR.PATCH format.
>> ```
>>
>> > B) Different versions of the spec are tags or branches of the same
document
>>
>> From http://docs.openstack.org/developer/pbr/semver.html :
>>
>> ```
>> Linux/Python Compatible Semantic Versioning 3.0.0
>>
>> This is a fork of Semantic Versioning 2.0. The specific changes have to
do with the format of pre-release and build labels, specifically to make
them not confusing when co-existing with Linux distribution packaging and
Python packaging. Inspiration for the format of the pre-release and build
labels came from Python’s PEP440.
>>
>> Changes vs SemVer 2.0¶
>>
>> dev versions are defined. These are extremely useful when dealing with
CI and CD systems when ‘every commit is a release’ is not feasible.All
versions have been made PEP-440 compatible, because of our deep roots in
Python. Pre-release versions are now separated by . not -, and use a/b/c
rather than alpha/beta etc.
>> ```
>>
>> Something like v1.0.01-eb4df7f[-linux64] would have greater traceability.
>>
>> >
>> > If it's B, then you'd either:
>> > 1) only build the latest version, and construct an index of links to
the unrendered old versions in vcs history
>> > 2) use a custom build/publishing worflow that pulls versions out of
history so they can be built as peers in the published version
>>
>> #. TBH I'm more concerned about determining downstream tool support from
MAJOR.MINOR.PATCH
>> (The PEP workflow is probably fine; I think there is need for  better
versioning under one heading).
>>
>> >
>> >
>> >
>> >
>> >
>> > On Sun, Sep 6, 2015 at 9:26 PM, Nick Coghlan <ncoghlan at gmail.com>
wrote:
>> >>
>> >> On 7 September 2015 at 14:11, Marcus Smith <qwcode at gmail.com> wrote:
>> >> >
>> >> >
>> >> >> > That way, the URL works as people expect, *and* the resulting
>> >> >> > destination gives a URL that (when inevitably copy-and-pasted)
will
>> >> >> > retain its meaning over time.
>> >> >>
>> >> >> Yes, ReadTheDocs does let us do that.
>> >> >
>> >> >
>> >> > well, it lets you do it for a whole project.
>> >>
>> >> RTD also has page redirects now:
>> >>
https://read-the-docs.readthedocs.org/en/latest/user-defined-redirects.html#page-redirects
>> >> (I thought the same thing you did, but found that when double
>> >> checking)
>> >>
>> >> So we *could* redirect unqualified links to qualified ones if we
>> >> wanted to. I just don't want to :)
>> >>
>> >> Cheers,
>> >> Nick.
>> >>
>> >> --
>> >> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
>> >
>> >
>> >
>> > _______________________________________________
>> > Distutils-SIG maillist  -  Distutils-SIG at python.org
>> > https://mail.python.org/mailman/listinfo/distutils-sig
>> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20150907/05adaa07/attachment.html>