[Distutils] PEP 345 update + RFC on "Requires-External" and "Requires-Python"
Kevin Teague
kevin at bud.ca
Sun Nov 15 07:18:41 CET 2009
On Nov 14, 2009, at 4:09 PM, Tarek Ziadé wrote:
>
> Last, "Requires-Python" is introduced to define the version of Python.
> I am not sure this is required anymore since Martin has added a Trove
> classifier
> for this. But in the meantime, this is stronger than a "simple"
> classifier I think.
>
+1 for Requires-Python.
This is a simpler field to understand than scanning through a list of
Trove classifiers. Both for filling out the metadata, and for
displaying on PyPI, since it would (arguably) be easier to read:
Requires Python: >2.4, <2.7
Than:
Categories:
Programming Language :: Python :: 2.4
Programming Language :: Python :: 2.5
Programming Language :: Python :: 2.6
Especially for packages with a large number of categories. Although
the easiest to read would be:
Requires Python: 2.4, 2.5, 2.6
At least I find it easier to map "2.4, 2.5, 2.6" to "requires Python
2.4, or Python 2.5 or Python 2.6" than translating from the >< ranges
into specific Python releases supported (which the Trove categories
already naturally suports). Perhaps just making a note in the PEP or
Distutils docs recommending this format "2.4, 2.5, 2.6", or at least
making it the primary example of using field, and recommending other
uses for special-case packages.
Erm, actually, re-reading the Requires Python section in PEP 345 I
guess the conditional operator is required, so it would actually be:
Requires Python: ==2.4, ==2.5, ==2.6
Is that right? Perhaps in the absence of a conditional operator, then
== should be the default, since I think it'd be easy to misunderstand
this field upon casual usage. But then it should also make explicit in
the PEP that ==2.5 is taken to mean only 2.5.0 or the entire sereis of
releases in the 2.5 line.
But then arguably there aren't even enough special cases to justify
the extra syntax to support things such as ">= 2.5.2"? I would imagine
that almost all packages, when they release just test against the
latest releases of whatever versions of Python that project supports?
Also for the minor releases the other Python implementations, they
aren't lock step with the CPython minor releases are they? e.g. Jython
has a 2.5.0 release and 2.5.1 release, but that 2.5.1 isn't the same
as CPython 2.5.1 (I could be wrong about this, haven't looked in depth).
Finally, it actually only makes sense to tag specific distributions
for which versions of Python they support. So for example the Grok
project:
Grok 1.0:
Requires Python: 2.4, 2.5
Grok 1.1:
Requires Python: 2.5, 2.6
Which means that they PyPI would say "Grok supports Python 2.5 and
Python 2.6" after 1.1 is released. Which might not be true if there
was still maintenance releases happening in the 1.0.x line. So they
what should the project specify here?
So maybe I'm -0 on this field, since it does seems ambigous or the
information is specific to the distributions and not the overall
project.
More information about the Distutils-SIG
mailing list