Re: python/dist/src/Lib/distutils/command upload.py, 1.3, 1.4

On Tue, 22 Mar 2005 12:32:46 -0800, loewis@users.sourceforge.net wrote:
Don't set the Python version for sdist uploads.
Why not? I realize that version is more important for pre-compiled extension modules, but it applies even to a pure python package. Source code that uses @decoration won't work in python 1.5 Defaulting to the version used to create the package isn't perfect, and may sometimes be too conservative -- but as a default, is it really worse than nothing? -jJ

On Tuesday 22 March 2005 16:09, Jim Jewett wrote:
Why not? I realize that version is more important for pre-compiled extension modules, but it applies even to a pure python package.
Source code that uses @decoration won't work in python 1.5
This is distinct from the version of Python used to build a distribution. I've noted this as a metadata field that is needed, and plan to draft a PEP to include this and a few others. What I don't want is to conflate fields that should be separate, and end up with crufty data in PyPI. It's better to know that some data is missing than to be wrong about it.
Defaulting to the version used to create the package isn't perfect, and may sometimes be too conservative -- but as a default, is it really worse than nothing?
Yes, because we can't tell the difference later. For now, you can include comments in the long description or on a project web page. A proper field will be added for this in the future (hopefully not too distant). -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

On Tue, 22 Mar 2005 18:00:50 -0500, "Fred L. Drake, Jr." <fdrake@acm.org> wrote:
On Tuesday 22 March 2005 16:09, Jim Jewett wrote:
Why not? I realize that version is more important for pre-compiled extension modules, but it applies even to a pure python package.
Source code that uses @decoration won't work in python 1.5
This is distinct from the version of Python used to build a distribution.
In theory, yes. My suspicion is that if people are using the defaults, then they are probably also using a python version that they have tested with -- and perhaps the only one that they have tested with.
Defaulting to the version used to create the package isn't perfect, and may sometimes be too conservative -- but as a default, is it really worse than nothing?
Yes, because we can't tell the difference later. For now, you can include comments in the long description or on a project web page. A proper field will be added for this in the future (hopefully not too distant).
How about changing it to tack on a "(guess)" instead of just deleting it? Or does that change break too many other things/cause too much ugliness for the timeframe it will be used in? -jJ

On Tuesday 22 March 2005 18:29, Jim Jewett wrote:
This is distinct from the version of Python used to build a distribution.
In theory, yes.
My suspicion is that if people are using the defaults, then they are probably also using a python version that they have tested with -- and perhaps the only one that they have tested with.
I think this varies substantially. I routinely test cross-version code with several versions of Python.
How about changing it to tack on a "(guess)" instead of just deleting it?
But it's not a guess for non-source distributions.
Or does that change break too many other things/cause too much ugliness for the timeframe it will be used in?
Too much ugliness. Remember, this field is attached to the uploaded file, not the release as a whole. Many packages are going to see uploads for two or more versions of Python (PyXML for example). Getting the metadata wrong is just too evil. Now that more people have seen the code for PyPI (and understand more of it), it'll be easier to implement new fields once they've been carefully defined. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org>

Zitat von Jim Jewett <jimjjewett@gmail.com>:
How about changing it to tack on a "(guess)" instead of just deleting it?
I think it would be confusing to users. Currently, the only version you would get into the database is 2.5, as earlier versions don't have the upload command. So we would have all sdist releases under packages/2.5, which would be too confusing, IMO.
Or does that change break too many other things/cause too much ugliness for the timeframe it will be used in?
It's also used to build the download link under python.org/packages. At the moment, changing the upload command would have no effect, since PyPI always puts sdist packages under packages/source, and clears the Python version if there is one. As Fred says, if a package has a minimum Python version, it should specify this - either in a new metadata field, or through an entry into Requires; PEP 314 somewhat suggests that you can do Depends: sys (>=2.3) Regards, Martin
participants (3)
-
Fred L. Drake, Jr.
-
Jim Jewett
-
martin@v.loewis.de