[Python-checkins] r50978 - in python/trunk: Lib/distutils/__init__.py Misc/NEWS

[M.-A. Lemburg]

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 ! ::::