<div dir="ltr"><p><br></p><div><p dir="ltr"><br>
On Sep 7, 2015 12:51 PM, "Marcus Smith" <<a href="mailto:qwcode@gmail.com" target="_blank">qwcode@gmail.com</a>> wrote:<br>
><br>
> Wes, this isn't about the versioning scheme for Specs or PEPS.<br>
> For *whatever* scheme we have, my discussion was about how to render all the "current" versions we support in a Sphinx project.</p>
<p dir="ltr">More or less itertools.product and a sphinx directive for ~CSVW?</p>
<p>Marcus, we could change the subject line.</p><p>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 ] ] ]]].</p><p>Possible subject lines:</p><p dir="ltr">* [ ] Add RDFa to pypi and warehouse<br>* [ ] Add JSONLD to pypi and warehouse<br>* "PEP ???: Metadata 3.0.1" * "Re: [Python-ideas] Increasing public package discoverability (was: Adding jsonschema to the standard library)"</p><div> * <a href="https://groups.google.com/d/msg/python-ideas/3MRVM6C6bQU/76hWP7bFgiwJ">https://groups.google.com/d/msg/python-ideas/3MRVM6C6bQU/76hWP7bFgiwJ</a><br><div> * <a href="https://groups.google.com/d/msg/python-ideas/3MRVM6C6bQU/VXq3yHcrCxcJ">https://groups.google.com/d/msg/python-ideas/3MRVM6C6bQU/VXq3yHcrCxcJ</a></div><div><br></div><div>```</div><div><div style="font-size:12.8px">So there is a <a href="http://schema.org/SoftwareApplication" target="_blank">schema.org/SoftwareApplication</a> (or doap:Project, or seon:) Resource,</div><div style="font-size:12.8px">which has</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">* a unique URI (e.g. <a href="http://python.org/pypi/readme" target="_blank">http://python.org/pypi/readme</a>)</div><div style="font-size:12.8px">* JSON metadata extracted from setup.py into pydist.json (setuptools, wheel)</div><div style="font-size:12.8px"> - [ ] create JSON-LD @context</div><div style="font-size:12.8px"> - [ ] create mappings to standard schema</div><div style="font-size:12.8px"> * [ ] <a href="http://schema.org/SoftwareApplication" target="_blank">http://schema.org/SoftwareApplication</a></div><div style="font-size:12.8px"> * [ ] <a href="http://schema.org/SoftwareSourceCode" target="_blank">http://schema.org/SoftwareSourceCode</a></div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">In terms of <a href="http://schema.org/" target="_blank">schema.org</a>, a Django <span class="">Packages</span> resource has:</div><div style="font-size:12.8px"><br></div><div style="font-size:12.8px">* [ ] a unique URI</div><div style="font-size:12.8px">* [ ] typed features (predicates with ranges)</div><div style="font-size:12.8px">* [ ] <a href="http://schema.org/review" target="_blank">http://schema.org/review</a></div><div style="font-size:12.8px">* [ ] <a href="http://schema.org/VoteAction" target="_blank">http://schema.org/VoteAction</a></div><div style="font-size:12.8px">* [ ] <a href="http://schema.org/LikeAction" target="_blank">http://schema.org/LikeAction</a></div><div style="font-size:12.8px">```</div></div></div>There is a matrix of packages that could, should, are uploaded;<br>which is a subset of a [giant global] graph;<br>which can be most easily represented in an RDF graph representation format like RDFa, JSON-LD, CSVW.</div><div><br></div><div>* setup.py <br>* requirements[-test|-docs][-dev][.peep].txt<br>* tox.ini -- tox grid (+docker = dox)<br>* Jenkins grid</div><div>* --> Pypi (e.g. with twine)<br>
<br></div><div>This does something more sequential than itertools.product<br>w/ a Requirement namedtuple and a RequirementsMap to iterate through (for generating combinations of requirements-{test,dev,{extras}}:</div><div>* <a href="https://github.com/westurner/pyleset/blob/57140bcef53/setup.py">https://github.com/westurner/pyleset/blob/57140bcef53/setup.py</a><br>* <a href="https://github.com/westurner/pyleset/tree/57140bcef53/requirements">https://github.com/westurner/pyleset/tree/57140bcef53/requirements</a>
<p dir="ltr">> in short, should the current versions we want to publish be distinct documents or not.<br>
><br>
> > The PEP workflow is probably fine<br>
><br>
> 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.</p>
<p dir="ltr">How would you add that metadata to the version string (according to PEP 440)? Semver 3.0 (pbr)</p><p dir="ltr"><font color="#3e4349" face="Arial, sans-serif"><span style="font-size:14.4px;line-height:21.6px">From <a href="http://docs.openstack.org/developer/pbr/semver.html">http://docs.openstack.org/developer/pbr/semver.html</a> :</span></font><br></p> 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
<p dir="ltr">><br>
><br>
> On Mon, Sep 7, 2015 at 9:40 AM, Wes Turner <<a href="mailto:wes.turner@gmail.com" target="_blank">wes.turner@gmail.com</a>> wrote:<br>
>><br>
>> MAJOR.MINOR.PATCH[-rev] would be helpful for these (and other) PEPs.<br>
>><br>
>> On Sep 7, 2015 10:36 AM, "Marcus Smith" <<a href="mailto:qwcode@gmail.com" target="_blank">qwcode@gmail.com</a>> wrote:<br>
>> ><br>
>> > I'm still unclear on whether you'd want A or B:<br>
>> ><br>
>> > A) Different major/minor versions of the spec are different documents<br>
>><br>
>> From <a href="http://semver.org" target="_blank">http://semver.org</a> Semantic Versioning 2.0 :<br>
>><br>
>> ```<br>
>> Given a version number MAJOR.MINOR.PATCH, increment the:<br>
>><br>
>> - MAJOR version when you make incompatible API changes,<br>
>> - MINOR version when you add functionality in a backwards-compatible manner, and<br>
>> - PATCH version when you make backwards-compatible bug fixes.<br>
>><br>
>> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.<br>
>> ```<br>
>><br>
>> > B) Different versions of the spec are tags or branches of the same document<br>
>><br>
>> From <a href="http://docs.openstack.org/developer/pbr/semver.html" target="_blank">http://docs.openstack.org/developer/pbr/semver.html</a> :<br>
>><br>
>> ```<br>
>> Linux/Python Compatible Semantic Versioning 3.0.0<br>
>><br>
>> 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.<br>
>><br>
>> Changes vs SemVer 2.0¶<br>
>><br>
>> 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.<br>
>> ```<br>
>><br>
>> Something like v1.0.01-eb4df7f[-linux64] would have greater traceability.<br>
>><br>
>> ><br>
>> > If it's B, then you'd either:<br>
>> > 1) only build the latest version, and construct an index of links to the unrendered old versions in vcs history<br>
>> > 2) use a custom build/publishing worflow that pulls versions out of history so they can be built as peers in the published version<br>
>><br>
>> #. TBH I'm more concerned about determining downstream tool support from MAJOR.MINOR.PATCH<br>
>> (The PEP workflow is probably fine; I think there is need for better versioning under one heading).<br>
>><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> ><br>
>> > On Sun, Sep 6, 2015 at 9:26 PM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>> wrote:<br>
>> >><br>
>> >> On 7 September 2015 at 14:11, Marcus Smith <<a href="mailto:qwcode@gmail.com" target="_blank">qwcode@gmail.com</a>> wrote:<br>
>> >> ><br>
>> >> ><br>
>> >> >> > That way, the URL works as people expect, *and* the resulting<br>
>> >> >> > destination gives a URL that (when inevitably copy-and-pasted) will<br>
>> >> >> > retain its meaning over time.<br>
>> >> >><br>
>> >> >> Yes, ReadTheDocs does let us do that.<br>
>> >> ><br>
>> >> ><br>
>> >> > well, it lets you do it for a whole project.<br>
>> >><br>
>> >> RTD also has page redirects now:<br>
>> >> <a href="https://read-the-docs.readthedocs.org/en/latest/user-defined-redirects.html#page-redirects" target="_blank">https://read-the-docs.readthedocs.org/en/latest/user-defined-redirects.html#page-redirects</a><br>
>> >> (I thought the same thing you did, but found that when double<br>
>> >> checking)<br>
>> >><br>
>> >> So we *could* redirect unqualified links to qualified ones if we<br>
>> >> wanted to. I just don't want to :)<br>
>> >><br>
>> >> Cheers,<br>
>> >> Nick.<br>
>> >><br>
>> >> --<br>
>> >> Nick Coghlan | <a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a> | Brisbane, Australia<br>
>> ><br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > Distutils-SIG maillist - <a href="mailto:Distutils-SIG@python.org" target="_blank">Distutils-SIG@python.org</a><br>
>> > <a href="https://mail.python.org/mailman/listinfo/distutils-sig" target="_blank">https://mail.python.org/mailman/listinfo/distutils-sig</a><br>
>> ><br>
><br>
><br>
</p>
</div></div>