On Oct 4, 2008, at 9:59 PM, Martin v. Löwis wrote:
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,
Why would that be a short-term fix? It would work for the entire life
time of Python 3, and can be easily extended for Python 4, so it
sounds
like a permanent solution to me.
As a permanent solution, you need to keep the problem statement in
mind,
though: to allow people to determine whether a package works with
Python 3.
The Setuptools dependencies fields are only for declaring library
dependencies, not dependencies such as the Python interpreter.
A problem with overloading the Categories field with Python version
compatability information is that it makes for a poor user-interface.
On the release page for a package, I'd rather see a Python Version
field than having to look through a potentially large list of
Categories.
There is a "Py Version" field for file uploads (which I'd really like
to tweak the UI to read "Python Version"), maybe if you could specify
for uploads of the "source" type the Python compatability of the
source file? Even without Python 3 it would be nice to upload a
source file and indicate that you've used a Python 2.5 or 2.6ism in
your code (or made use of newer standard library modules).
Although this raises the question, what is the recommended practice
for version numbering for distributions attempting to support both
Python 2 and 3? Say I have a distribution that I've made work with
Python 2.6 and can run on Python 3 after running it through 2to3. The
source code is different so that to me suggests different version
numbers - but the API will be the same, so maybe the same version
number should be used? That is should there be?
foobar-1.0-py2.6.tar.gz
foobar-1.0-py3.0.tar.gz
Or should it be something like?
foobar-1.0.tar.gz # Python 2
foobar-1.1.tar.gz # Python 3
Well, writing out that last example looks wrong to me, since 1.0 ->
1.1 suggests bug fixes and API changes to the package. But someone
could be thinking, "1.0 supports the Python 2 API and 1.1 supports the
Python 3 language API". So at any rate it'd be good to make the way to
handle this explicit in the (yet to be created) "2to3 central"
documentation resource.
_______________________________________________
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
