On Sat, Oct 4, 2008 at 2:22 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Antoine Pitrou wrote: >> Martin v. Löwis <martin <at> v.loewis.de> writes: >>>> This may be more complicated than it sounds, because you'd probably >>>> add a very general requirement-indicating feature to PyPI, not merely >>>> a 'supports 3.0' Boolean on each record, and requirements are actually >>>> pretty complicated: alternative packages, specific version numbers... >>> Can you propose a spec? >> >> Setuptools already has a syntax for declaring requirements. >> http://peak.telecommunity.com/DevCenter/setuptools#declaring-dependencies > > That is underspecified for the issue at hand: What *specifically* should > PyPI look for to determine 3.0 support in a package, and how > *specifically* should it display that? > > An alternative to specifying dependencies would be to specify a > classifier, e.g. > > Programming Language :: Python :: 3 > > or > > Programming Langauge :: Python3 > > Then, no changes to PyPI are needed (except for adding the classifier to > the database), and searching for Python-3-supporting packages could > go through http://pypi.python.org/pypi?%3Aaction=browse
Setuptools declares dependencies, but does not add a Python version requirement, like what was proposed in PEP 345 (http://www.python.org/dev/peps/pep-0345/) with a new metadata called 'Requires Python' Even if the problem is fixed in short term with a Trove classifier, the metadata of a package should provide this information imho. >From there PyPI should be able to provide the Python version directly. For a full list of dependencies this is another tough problem due to the dynamic nature of the metadata: you have to run setup.py to get the list of dependencies because they are determined by code. This is by design, and plans for a refactoring are being discussed in distutils-SIG since a few days. In any case, extending metadata with supported Python version could be a first simple, useful step to do in distutils and PyPI today. So the Python version comes as the same level than the Platform or the License. Tarek _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
