RE: [Distutils] Timeframe of 2.0 again?
From: M.-A. Lemburg [mailto:mal@lemburg.com]
Not so: in that case we'd have to keep in sync with at least 5 different versions of distutils deployed out there.
I'm sure I am missing something, so please forgive me if I'm labouring the obvious, but can't you retain all your current build environments (Python 1.5.2, 2.0, 2.1, 2.2, 2.3) and when 2.4 comes out just add that, and only use the new distutils with 2.4? [I'm wondering - is the thing I'm missing that you're using a single shared distutils with all of the Python versions? I can't see how that would work...] Or are you worried about setup.py not working with both the old and new distutils? That's a valid issue, but I'd assume that the new distutils would have to be careful not to break compatibility with old setup.py files. Once again, apologies if I'm being dense. My experience of distributing Python modules is nothing compared to yours, and I don't mean to imply that I think your concerns are invalid. I'm just interested in understanding the issue I've missed, so that I don't fall into the trap of assuming things are simpler than they really are :-) Paul
Moore, Paul wrote:
From: M.-A. Lemburg [mailto:mal@lemburg.com]
Not so: in that case we'd have to keep in sync with at least 5 different versions of distutils deployed out there.
I'm sure I am missing something, so please forgive me if I'm labouring the obvious, but can't you retain all your current build environments (Python 1.5.2, 2.0, 2.1, 2.2, 2.3) and when 2.4 comes out just add that, and only use the new distutils with 2.4?
[I'm wondering - is the thing I'm missing that you're using a single shared distutils with all of the Python versions? I can't see how that would work...]
As I said before, we are using distutils CVS for all Python versions we support.
Or are you worried about setup.py not working with both the old and new distutils? That's a valid issue, but I'd assume that the new distutils would have to be careful not to break compatibility with old setup.py files.
Right. We are adding many features to distutils which we need for supporting features like, e.g. automatic configuration, etc. These features rely heavily on subclassing and the way distutils is tied together. Supporting the more than 5 versions out there is not feasable in this kind of setup which is typical of distutils packaging, since distutils is designed to be extended in this way.
Once again, apologies if I'm being dense. My experience of distributing Python modules is nothing compared to yours, and I don't mean to imply that I think your concerns are invalid. I'm just interested in understanding the issue I've missed, so that I don't fall into the trap of assuming things are simpler than they really are :-)
I wouldn't mind having distutils optionally use features from 2.3 or 2.4, it's just that the code for supporting older versions than 2.1 should, IMHO, not be removed from the package. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Oct 27 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
participants (2)
-
M.-A. Lemburg
-
Moore, Paul