[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