r50978 - in python/trunk: Lib/distutils/__init__.py Misc/NEWS
Author: martin.v.loewis Date: Sun Jul 30 15:14:05 2006 New Revision: 50978 Modified: python/trunk/Lib/distutils/__init__.py python/trunk/Misc/NEWS Log: Base __version__ on sys.version_info, as distutils is no longer maintained separatedly. Modified: python/trunk/Lib/distutils/__init__.py ============================================================================== --- python/trunk/Lib/distutils/__init__.py (original) +++ python/trunk/Lib/distutils/__init__.py Sun Jul 30 15:14:05 2006 @@ -12,4 +12,6 @@ __revision__ = "$Id$" -__version__ = "2.5.0" +import sys +__version__ = "%d.%d.%d" % sys.version_info[:3] +del sys Modified: python/trunk/Misc/NEWS ============================================================================== --- python/trunk/Misc/NEWS (original) +++ python/trunk/Misc/NEWS Sun Jul 30 15:14:05 2006 @@ -80,7 +80,8 @@ side effects from one test to the next affect outcomes. ``DocTestFinder`` has been changed to sort the list of tests it returns. -- The distutils version has been changed to 2.5.0. +- The distutils version has been changed to 2.5.0, and are now kept + in sync with sys.version_info[:3]. - Bug #978833: Really close underlying socket in _socketobject.close.
martin.v.loewis wrote:
Author: martin.v.loewis Date: Sun Jul 30 15:14:05 2006 New Revision: 50978
Modified: python/trunk/Lib/distutils/__init__.py python/trunk/Misc/NEWS Log: Base __version__ on sys.version_info, as distutils is no longer maintained separatedly.
Modified: python/trunk/Lib/distutils/__init__.py ============================================================================== --- python/trunk/Lib/distutils/__init__.py (original) +++ python/trunk/Lib/distutils/__init__.py Sun Jul 30 15:14:05 2006 @@ -12,4 +12,6 @@
__revision__ = "$Id$"
-__version__ = "2.5.0" +import sys +__version__ = "%d.%d.%d" % sys.version_info[:3] +del sys
Won't this give a wrong answer if someone runs a mismatched distutils version? e.g. distutils 2.5.0 would claim to be distutils 2.4.3 if you ran it with the latest 2.4 release. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Nick Coghlan schrieb:
-__version__ = "2.5.0" +import sys +__version__ = "%d.%d.%d" % sys.version_info[:3] +del sys
Won't this give a wrong answer if someone runs a mismatched distutils version? e.g. distutils 2.5.0 would claim to be distutils 2.4.3 if you ran it with the latest 2.4 release.
How would you do this? Distutils is not released stand-alone anymore, so you explicitly need to fiddle with your Python installation. If you do this, you also have to update the distutils version, or it will give you the wrong version. You might have to do more backporting to use distutils, anyway, since it might not work at all with a previous Python version. Regards, Martin
Martin v. Löwis wrote:
Nick Coghlan schrieb:
-__version__ = "2.5.0" +import sys +__version__ = "%d.%d.%d" % sys.version_info[:3] +del sys Won't this give a wrong answer if someone runs a mismatched distutils version? e.g. distutils 2.5.0 would claim to be distutils 2.4.3 if you ran it with the latest 2.4 release.
I agree with Nick. The patch isn't all that helpful.
How would you do this? Distutils is not released stand-alone anymore,
Maybe not publically, but it's certainly possible to use a distutils package from SVN with Python 2.3 (and eGenix for example uses this approach in order to minimize the number of versions of distutils we have to support).
so you explicitly need to fiddle with your Python installation. If you do this, you also have to update the distutils version, or it will give you the wrong version. You might have to do more backporting to use distutils, anyway, since it might not work at all with a previous Python version.
setup.py files do have to check for the version of the distutils package they are used with and if distutil's version is simply a copy of sys.version the __version__ attribute is pretty much useless. I would much rather see distutils use its own version number again - not all Python releases do contain major changes in distutils. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 30 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
M.-A. Lemburg schrieb:
I agree with Nick. The patch isn't all that helpful.
So we are stuck. Anthony Baxter wants this automatically synchronized.
Maybe not publically, but it's certainly possible to use a distutils package from SVN with Python 2.3 (and eGenix for example uses this approach in order to minimize the number of versions of distutils we have to support).
So you need to do the backporting on your own. This usage is not officially supported; it's not a design goal anymore that distutils works with any Python version except the one that it shipped with. Or else, you need to step forward as the distutils maintainer who officially keeps backwards compatibility with previous versions, corrects incompatibilities, performs the testing against previous versions, updates version numbers should they need updating, and so on. Regards, Martin
On Monday 31 July 2006 02:35, Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
I agree with Nick. The patch isn't all that helpful.
So we are stuck. Anthony Baxter wants this automatically synchronized.
I want less places in the Python standard library that contain version numbers that have to be updated constantly. If you (or anyone else) wants to cut a standalone release of distutils, you should take care to update the version number in the standalone code appropriately. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
On Monday 31 July 2006 02:35, Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
I agree with Nick. The patch isn't all that helpful. So we are stuck. Anthony Baxter wants this automatically synchronized.
I want less places in the Python standard library that contain version numbers that have to be updated constantly. If you (or anyone else) wants to cut a standalone release of distutils, you should take care to update the version number in the standalone code appropriately.
I don't want to cut a separate release: what we're doing is using the SVN version of distutils on all Python versions since Python 2.3 (and the Python 2.3 shipped version for all version before that). With the patch, setup.py scripts will now regard the distutils package as being version 2.x.y when run with Python 2.x.y and apply fixes needed for that distutils version. distutils is a complicated package and I think this warrants having a single version number for it which is independent of the Python version numbering. Also note that the Python 2.1 requirement for distutils was dropped without any discussion on the distutils SIG: http://svn.python.org/view?rev=1982&view=rev http://mail.python.org/pipermail/distutils-sig/2005-March/thread.html So I question that decision (which I just found out by looking at PEP 291 today) as well. If you need a maintainer for the distutils version number, I'd be happy to take that role and I'd also like to propose to re-add the Python 2.1 requirement back to PEP 291 again. It really helps a lot if you can use the most recent distutils versions for all Python versions people commonly use today. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 31 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
On Monday 31 July 2006 20:38, M.-A. Lemburg wrote:
I want less places in the Python standard library that contain version numbers that have to be updated constantly. If you (or anyone else) wants to cut a standalone release of distutils, you should take care to update the version number in the standalone code appropriately.
I don't want to cut a separate release: what we're doing is using the SVN version of distutils on all Python versions since Python 2.3 (and the Python 2.3 shipped version for all version before that).
Then you are in some way pulling down the SVN version of distutils. When you do this, you could in some way mark the version. But if you're pulling in SVN, what's a version number? Is a release from 6 months ago (before 2.5a1) version 2.5? 2.5a0? 2.4? If the version number isn't being updated (as it hasn't been) then isn't it safe to say it's meaningless from your point of view? After all, you didn't notice before now that it hadn't been updated to 2.5. That would suggest that it doesn't actually matter.
With the patch, setup.py scripts will now regard the distutils package as being version 2.x.y when run with Python 2.x.y and apply fixes needed for that distutils version.
I could see the patch maybe being augmented to search for, say, distutils/version.txt - if found, it could use that instead of the Python version. I'm not propsosing to do this, as I have no need for it.
distutils is a complicated package and I think this warrants having a single version number for it which is independent of the Python version numbering.
It's not had a seperate release in a very, very long time. I don't see why the code being complicated means it somehow warrants it's own version number. Plenty of chunks of the standard library are complicated - admittedly, few bits are as hairy as distutils <wink>. If you're the only person cutting your own private releases of distutils from SVN, it would seem that you can also be the one to change the version number for your own private releases, no?
Also note that the Python 2.1 requirement for distutils was dropped without any discussion on the distutils SIG:
Er, it was discussed last year. If you need a version that will work on < 2.3, use a version from before the change. If there's no separate releases, why should the code be un-necessarily constrained to older versions?
If you need a maintainer for the distutils version number, I'd be happy to take that role and I'd also like to propose to re-add the Python 2.1 requirement back to PEP 291 again.
Are you proposing to cut seperate distutils releases? If not, how is it a problem to change the version number (maybe using the above scheme) when you pull the SVN version.
It really helps a lot if you can use the most recent distutils versions for all Python versions people commonly use today.
_Is_ 2.1 commonly used? I'd question that. Python 2.2 was released December 2001 - the last release of 2.1 (2.1.3) was April 2002 - over 4 years ago. Scattered version numbers inside the stdlib are a problem. They don't get updated and they only make sense if there's actual separate releases. Even then, the person cutting the separate releases can make the changes to do this. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
On Monday 31 July 2006 20:38, M.-A. Lemburg wrote:
I want less places in the Python standard library that contain version numbers that have to be updated constantly. If you (or anyone else) wants to cut a standalone release of distutils, you should take care to update the version number in the standalone code appropriately. I don't want to cut a separate release: what we're doing is using the SVN version of distutils on all Python versions since Python 2.3 (and the Python 2.3 shipped version for all version before that).
Then you are in some way pulling down the SVN version of distutils. When you do this, you could in some way mark the version. But if you're pulling in SVN, what's a version number? Is a release from 6 months ago (before 2.5a1) version 2.5? 2.5a0? 2.4? If the version number isn't being updated (as it hasn't been) then isn't it safe to say it's meaningless from your point of view? After all, you didn't notice before now that it hadn't been updated to 2.5. That would suggest that it doesn't actually matter.
The fact that it hasn't mattered between the 2.4 and now doesn't really mean that it won't matter in the future, right ? Of course, we can manually create our own internal distro of distutils where we then hard-code the version number, but don't you think that a package that is designed to make Python distribution easy should not be tied to a single Python version ?
With the patch, setup.py scripts will now regard the distutils package as being version 2.x.y when run with Python 2.x.y and apply fixes needed for that distutils version.
I could see the patch maybe being augmented to search for, say, distutils/version.txt - if found, it could use that instead of the Python version. I'm not propsosing to do this, as I have no need for it.
That would only cause problems with the Python import scheme. It's not necessary clear where to look for that .txt file (think ZIP archives, py2exe, mxCGIPython, etc.).
distutils is a complicated package and I think this warrants having a single version number for it which is independent of the Python version numbering.
It's not had a seperate release in a very, very long time. I don't see why the code being complicated means it somehow warrants it's own version number. Plenty of chunks of the standard library are complicated - admittedly, few bits are as hairy as distutils <wink>. If you're the only person cutting your own private releases of distutils from SVN, it would seem that you can also be the one to change the version number for your own private releases, no?
Of course. However, I don't think that we're the only guys doing Python releases of products out there. OTOH, I do know that it's always better to use the latest version of distutils available - even if only to make use of new features that we didn't have in previous distutils versions. The fact that we don't have separate distutils releases doesn't really make a difference, IMHO, since you can just as well grab the code from the Python release and then use it for other Python versions. This is just a matter of whether you want to save the hassle of cutting a release. The package itself can still work with different Python versions.
Also note that the Python 2.1 requirement for distutils was dropped without any discussion on the distutils SIG:
Er, it was discussed last year. If you need a version that will work on < 2.3, use a version from before the change. If there's no separate releases, why should the code be un-necessarily constrained to older versions?
According to Andrew's checkin message it was discussed at some sprint at PyCon 2005, so yes, it probably was discussed, but not in public AFAIK. Maybe I missed the discussion - if you have some pointers, that'd be great. Again, I don't really see why having stand-alone releases is a requirement for supporting a version number of a sub-package. Many modules in the stdlib have their own version number and for a good reason. If they don't get updated, I'd consider that a bug, but not an argument to remove the version number.
If you need a maintainer for the distutils version number, I'd be happy to take that role and I'd also like to propose to re-add the Python 2.1 requirement back to PEP 291 again.
Are you proposing to cut seperate distutils releases? If not, how is it a problem to change the version number (maybe using the above scheme) when you pull the SVN version.
No, I'm proposing to maintain the version number, ie. bump it when necessary, but keep it static and separate from the Python version number. I wouldn't have anything against creating separate distutils packages either - the problem with these, though, is that it's not easily possible to upgrade Python stdlib packages... http://www.python.org/dev/peps/pep-0297/
It really helps a lot if you can use the most recent distutils versions for all Python versions people commonly use today.
_Is_ 2.1 commonly used? I'd question that. Python 2.2 was released December 2001 - the last release of 2.1 (2.1.3) was April 2002 - over 4 years ago.
Python versions commonly in use today are Python 2.3 and 2.4. Python 2.2 is also still being used in production, though, not a lot. Python 2.1 is still a requirement in a lot of older Python and Zope installations. I'd be happy with going for Python 2.3 compatibility in distutils, but please don't let the distutils drop the Python 2.3 compatibility for at least a few more years. It doesn't buy distutils anything much anyway.
Scattered version numbers inside the stdlib are a problem. They don't get updated and they only make sense if there's actual separate releases. Even then, the person cutting the separate releases can make the changes to do this.
You're missing the point: the version number in distutils is needed for introspection purposes by setup.py scripts. If you make the version number dynamic you confuse those scripts - and there are lots of those scripts in the Python universe. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 31 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
Anthony Baxter wrote:
On Monday 31 July 2006 02:35, Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
I agree with Nick. The patch isn't all that helpful. So we are stuck. Anthony Baxter wants this automatically synchronized.
I want less places in the Python standard library that contain version numbers that have to be updated constantly. If you (or anyone else) wants to cut a standalone release of distutils, you should take care to update the version number in the standalone code appropriately.
Could we please revert the patch to have the distutils version number generated rather than being a fixed literal before b3 and then have a proper discussion about this whole issue on either the distutils SIG list or python-dev ? Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 02 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
M.-A. Lemburg schrieb:
Anthony Baxter wrote:
On Monday 31 July 2006 02:35, Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
I agree with Nick. The patch isn't all that helpful. So we are stuck. Anthony Baxter wants this automatically synchronized.
I want less places in the Python standard library that contain version numbers that have to be updated constantly. If you (or anyone else) wants to cut a standalone release of distutils, you should take care to update the version number in the standalone code appropriately.
Could we please revert the patch to have the distutils version number generated rather than being a fixed literal before b3 and then have a proper discussion about this whole issue on either the distutils SIG list or python-dev ?
I would like to support MaL on this issue. Thomas
M.-A. Lemburg schrieb:
Could we please revert the patch to have the distutils version number generated rather than being a fixed literal before b3 and then have a proper discussion about this whole issue on either the distutils SIG list or python-dev ?
Not sure who "we" is; I personally won't revert it, as I think it is the right thing to do (I spent already too much time on it, and if I hadn't acted, the version number would still falsely be 2.4.0). I don't see the need to revert it now even if some consensus arrives that it should be changed back after b3, or even after 2.5.0 is released: it's possible to change it back at any time without breaking anything. Regards, Martin
Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
Could we please revert the patch to have the distutils version number generated rather than being a fixed literal before b3 and then have a proper discussion about this whole issue on either the distutils SIG list or python-dev ?
Not sure who "we" is; I personally won't revert it, as I think it is the right thing to do (I spent already too much time on it, and if I hadn't acted, the version number would still falsely be 2.4.0).
I don't see the need to revert it now even if some consensus arrives that it should be changed back after b3, or even after 2.5.0 is released: it's possible to change it back at any time without breaking anything.
We have had three responses from people seeing a problem with the patch: from Nick, Thomas and myself. I think that warrants backing out the change again. I don't really see maintaining the version number as string literal as such a big problem to have long discussions over it. I also mentioned that I would volunteer to take care of bumping the version number as necessary. If Anthony gives the OK, I'll revert the patch and change the attribute back to the '2.5.0' string literal. This will then not break anything. In a sense, making the version number dynamic is adding a new controversial feature. IMHO, that's a no-no this late in the release process and should be left untouched until the next release - with a chance to have a proper discussion first. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 02 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
On Thursday 03 August 2006 04:59, M.-A. Lemburg wrote:
If Anthony gives the OK, I'll revert the patch and change the attribute back to the '2.5.0' string literal. This will then not break anything.
It's not going to break anything. If you want to cut a separate release, set the version number. That's hardly an issue. Really, you should be checking for functionality, not individual version numbers - in the same way as duck-typing for objects.
In a sense, making the version number dynamic is adding a new controversial feature. IMHO, that's a no-no this late in the release process and should be left untouched until the next release - with a chance to have a proper discussion first.
I'm not changing it now. If the consensus is that having fiddly version numbers strewn through the standard library is a good idea, it can be changed before c1. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
On Thursday 03 August 2006 04:59, M.-A. Lemburg wrote:
If Anthony gives the OK, I'll revert the patch and change the attribute back to the '2.5.0' string literal. This will then not break anything.
It's not going to break anything. If you want to cut a separate release, set the version number. That's hardly an issue. Really, you should be checking for functionality, not individual version numbers - in the same way as duck-typing for objects.
Oh, come on, that's just silly and you know that. We're not talking about a single object that you can test for a feature and besides, how are you going to check for bugs in the code when you don't have a version number to test against ? If it were that simple, we might as well drop the whole concept of version numbers in Python altogether. BTW, one of the key complaints about distutils is that it doesn't have dependency checking based on version numbers...
In a sense, making the version number dynamic is adding a new controversial feature. IMHO, that's a no-no this late in the release process and should be left untouched until the next release - with a chance to have a proper discussion first.
I'm not changing it now. If the consensus is that having fiddly version numbers strewn through the standard library is a good idea, it can be changed before c1.
Fair enough, then we'll change it back for c1. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 03 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
Martin v. Löwis wrote:
M.-A. Lemburg schrieb:
I agree with Nick. The patch isn't all that helpful.
So we are stuck. Anthony Baxter wants this automatically synchronized.
I think we can go with "don't do that, but if you do do it, force __version__ to the appropriate value". I originally thought it would make sense to have a minimum version that it would report, but I've realised that still doesn't solve the problem if you have deliberately pulled a version of distutils out of SVN. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
participants (6)
-
"Martin v. Löwis" -
Anthony Baxter -
M.-A. Lemburg -
martin.v.loewis -
Nick Coghlan -
Thomas Heller