<div><span style="color: rgb(160, 160, 168); ">On Sunday, February 3, 2013 at 8:32 AM, Nick Coghlan wrote:</span></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
<span><div><br></div><div>Keywords (optional)</div><div>-------------------</div><div><br></div><div>A list of additional whitespace separated keywords to be used to assist</div><div>searching for the distribution in a larger catalog.</div><div><br></div><div>Example::</div><div><br></div><div> Keywords: dog puppy voting election</div></span></blockquote><div>I wonder if it makes sense to make this a multi use field instead of</div><div>a whitespace separated field. It always felt really dirty to me that</div><div>this was essentially a list but wasn't treat as one. Not a requirement</div><div>but just a thought.</div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><br></div><div>Version Scheme</div><div>==============</div><div><br></div><div>Version numbers must comply with the following scheme::</div><div><br></div><div> N.N[.N]+[{a|b|c|rc}N][.postN][.devN]</div><div><br></div><div>Parser implementations should be aware that versions of the Metadata</div><div>specification prior to v1.2 (PEP 345) do not specify a standard version</div><div>numbering scheme. For metadata v1.2, it is recommended that implementations</div><div>use the sorting scheme defined below rather than the one defined in PEP 386.</div><div><br></div><div><br></div><div>Suffixes and Ordering</div><div>---------------------</div><div><br></div><div>The following suffixes are the only ones allowed at the given level of the</div><div>version hierarchy and they are ordered as listed.</div><div><br></div><div>Within a numeric release (``1.0``, ``2.7.3``)::</div><div><br></div><div> .devN, aN, bN, cN, rcN, <no suffix>, .postN</div><div><br></div><div>Within an alpha (``1.0a1``), beta (``1.0b1``), or release candidate</div><div>(``1.0c1``, ``1.0rc1``)::</div><div><br></div><div> .devN, <no suffix>, .postN</div><div><br></div><div>Within a post release (``1.0.post1``)::</div><div><br></div><div> devN, <no suffix></div><div><br></div><div>Note that ``devN`` and ``postN`` must always be preceded by a dot, even</div><div>when used immediately following a numeric version (e.g. ``1.0.dev456``,</div><div>``1.0.post1``).</div><div><br></div><div>Within a given suffix, ordering is by the value of the numeric component.</div><div><br></div><div>Note that `rc` will always sort after `c` (regardless of the numeric</div><div>component) although they are semantically equivalent. It is suggested</div><div>that within a particular project you do not mix `c` and `rc`, especially</div><div>within the same numeric version.</div><div><br></div><div><br></div><div>Example Version Order</div><div>---------------------</div><div><br></div><div>::</div><div><br></div><div> 1.0.dev456</div><div> 1.0a1</div><div> 1.0a2.dev456</div><div> 1.0a12.dev456</div><div> 1.0a12</div><div> 1.0b1.dev456</div><div> 1.0b2</div><div> 1.0b2.post345</div><div> 1.0c1.dev456</div><div> 1.0c1</div><div> 1.0</div><div> 1.0.post456.dev34</div><div> 1.0.post456</div><div> 1.1.dev1</div></span></blockquote><div>Just to point out that this a minor departure from PEP386 (on purpose) and</div><div>a simplification of the rules. The major point being to enable backwards</div><div>compatibility with setuptools/distribute.</div><div><br></div><div><div>In [1]: import pkg_resources</div><div>In [2]: import distutils2.version</div><div>In [3]: versions = ["1.0.dev456", "1.0a1", "1.0a2.dev456", "1.0a12.dev456", "1.0a12", "1.0b1.dev456", "1.0b2", "1.0b2.post345", "1.0c1.dev456", "1.0c1", "1.0", "1.0.post456.dev34", "1.0.post456", "1.1.dev1"]</div><div>In [4]: versions2 = sorted(versions, key=pkg_resources.parse_version)</div><div>In [5]: versions == versions2</div><div>Out[5]: True</div></div><div>In [6]: versions3 = sorted(versions, key=distutils2.version.NormalizedVersion)</div><div><div>In [7]: versions == versions3</div><div>Out[7]: False</div></div><div><br></div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div>Version Specifiers</div><div>==================</div><div><br></div><div>A version specifier consists of a series of version clauses, separated by</div><div>commas. Each version clause consists of an optional comparison operator</div><div>followed by a version number. For example::</div><div><br></div><div> 0.9, >= 1.0, != 1.3.4, < 2.0</div><div><br></div><div>Each version number must be in the standard format described in</div><div>`Version Scheme`_.</div></span></blockquote><div>So what happens when I'm writing a package and want to depend on</div><div>something that does not use the Version Scheme? Do we just</div><div>say "You can't do that?". </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><br></div><div>Comparison operators must be one of ``<``, ``>``, ``<=``, ``>=``, ``==``</div><div>and ``!=``.</div><div><br></div><div>When no comparison operator is provided, it is equivalent to using the</div><div>following pair of version clauses::</div><div><br></div><div> >= V, < V+1</div><div><br></div><div>where ``V+1`` is the "next version" after ``V``, as determined by</div><div>incrementing the last numeric component in ``V`` (for example, if</div><div>``V == 1.0a3``, then ``V+1 == 1.0a4``, while if ``V == 1.0``, then</div><div>``V+1 == 1.1``).</div><div><br></div><div>The comma (",") is equivalent to a logical **and** operator.</div><div><br></div><div>Whitespace between a conditional operator and the following version number</div><div>is optional, as is the whitespace around the commas.</div><div><br></div><div>Pre-releases of any kind (indicated by the presence of ``dev``, ``a``,</div><div>``b``, ``c`` or ``rc`` in the version number) are implicitly excluded</div><div>from all version specifiers, *unless* a pre-release version is explicitly</div><div>mentioned in one of the clauses. For example, this specifier implicitly</div><div>excludes all pre-releases of later versions::</div><div><br></div><div> >= 1.0</div><div><br></div><div>While these specifiers would include them::</div><div><br></div><div> >= 1.0a1</div><div> >= 1.0c1</div><div> >= 1.0, != 1.0b2</div><div> >= 1.0, < 2.0.dev123</div><div><br></div><div>Dependency resolution tools should use the above rules by default, but may</div><div>also allow users to request the following alternative behaviours:</div><div><br></div><div>* accept already installed pre-releases for all version specifiers</div><div>* retrieve and install available pre-releases for all version specifiers</div><div><br></div><div>Post releases and purely numeric releases receive no special treatment -</div><div>they are always included unless explicitly excluded.</div><div><br></div><div>Given the above rules, projects which include the ``.0`` suffix for the</div><div>first release in a series, such as ``2.5.0``, can easily refer specifically</div><div>to that version with the clause ``2.5.0``, while the clause ``2.5`` refers</div><div>to that entire series. Projects which omit the ".0" suffix for the first</div><div>release of a series, by using a version string like ``2.5`` rather than</div><div>``2.5.0``, will need to use an explicit clause like ``2.5, < 2.5.1`` to</div><div>refer specifically to that initial release.</div></span></blockquote><div>Should replace this to be ==2.5 instead of 2.5, < 2.5.1 as that's</div><div>not guaranteed to be the same as ==2.5. Also -==2.5.0 really. A</div><div>bare clause should not be expected to match exactly</div><div>anything.</div><div><br></div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;"><span><div><br></div><div> - ``Requires-Python`` (explicitly flagged as multiple use)</div></span></blockquote><div>What's the use case for a multiple use Requires-Python? Are Multiple</div><div>uses OR'd while single use but comma seperated AND'd? </div><div><br>
</div>