Would it be possible that a standard be established for listing in PyPI classifiers which versions of a package is known to operate? Using James Bennett's django-registration at http://pypi.python.org/pypi/django-registration as an example (see my bolded, last two lines to understand what I'm trying to demonstrate):
Development Status :: 5 - Production/StableThe metadata system I'm writing about in this blog post is specified on the distutils documentation page.
Environment :: Web Environment
Framework :: Django
Intended Audience :: Developers
License :: OSI Approved :: BSD License
Operating System :: OS Independent
Programming Language :: Python
Topic :: Utilities
Python Versions :: 2.4, 2.5, 2.6, 2.7
Django Versions :: 0.96, 1.0, 1.1, 1.2.1, 1.3
I picked a Django package but this could be for Zope, Pyramid, PyQT, or anything.
If we had something like this in place then people could quickly identify on PyPI and other resources if a tool can be of use to them or if it needs to be updated to the latest code base. If this already exists, then can someone point me at the existing specification so I can promote it?
Edit: Noah Kantrowitz suggested I take a look at the 'requires' keyword which is part of the distutils spec. However, this does not show up in the PyPI API (http://wiki.python.org/moin/PyPiXmlRpc) and so doesn't fit our needs.
7 comments:
It's quite easy to enhance the XML-RPC interface.
I am very glad you brought up this topic. There is already a convention followed for the python and framework versions, but it appears that not enough people are aware of it. It should be included in the standard distutils documentation.
You can see the full list of classifiers here:
http://pypi.python.org/pypi?%3Aaction=list_classifiers
For the python language version the classifier is:
Programming Language :: Python ::
With each version on it's own line. That way you can browse the repository by python version (see the bottom of the page):
http://pypi.python.org/pypi?:action=browse&c=214
There is also support for frameworks which you can see on that page as well. There it is done with:
Framework :: Django ::
There is Zope, Plone, and a number of other frameworks already there.
In the example you gave the proper, and supported way of writing the metadata is:
Programming Language :: Python
Programming Language :: Python :: 2.4
Programming Language :: Python :: 2.5
Programming Language :: Python :: 2.6
Programming Language :: Python :: 2.7
Framework :: Django
Framework :: Django :: 0.96
Framework :: Django :: 1.0
Framework :: Django :: 1.1
Framework :: Django :: 1.2.1
Framework :: Django :: 1.3
People should already be following this convention, and it should be advertised more.
@Richard, I would love to see the XML-RPC interface for PyPI enhanced! However, as @Doug pointed out, the information is there already in the classifiers.
The question then becomes does it make sense to have PyPI slurp information out of the classifiers that are already returned by the XML-RPC API? If so, I'm happy to tes the results via Django Packages and another project I'm on.
Another issue to be raised is educating the Python audience at large about classifiers.
Generally speaking if there's a need for something in PyPI it can be done. We (Martin von Löwis and myself) just need to be aware of it. Which we usually aren't, for some reason. And people write HTML scapers instead.
Hi,
The classifiers already exists for python versions:
Programming Language :: Python :: 2
Programming Language :: Python :: 2.3
Programming Language :: Python :: 2.4
Programming Language :: Python :: 2.5
Programming Language :: Python :: 2.6
Programming Language :: Python :: 2.7
Programming Language :: Python :: 3
Programming Language :: Python :: 3.0
Programming Language :: Python :: 3.1
Programming Language :: Python :: 3.2
BTW, I'm not sure the right way to define that a project is dependent on which or which version of a framework is to use the classifiers.
We already can do that using the requires fields, and it will be easy to deal with them with the upcoming distutils2 release, because the setup.py thing will disappear, going to be replaced by a static setup.cfg file.
@Richard - Maybe a bigger typeface or more precedence to to the bug tracker and help links?
*sigh* oops! I was wrong about the framework version classifiers. They are not part of the list. I should double check my facts first. Sorry... Richard and others should be able to add that feature though.
We should put out a request for feedback on which versions need official listing for which frameworks. I would not expect the PyPi folks to track down all the versions themselves. Nor should al the potential versions be included IMHO. For example Django 0.92 is just out.
Post a Comment