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.