backwards compatibility of distutils?
When is it ok to lose the backward-compatibility of distutils? Going through the code, there's at least two entire modules (log and fancy_getopt) that should be removed in favour of the new logging and optparse modules. Obviously this isn't possible if 1.5.2 compatibility is to be kept. Or should they be replaced with copies of the logging and optparse modules in the distutils CVS tree? Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
When is it ok to lose the backward-compatibility of distutils? Going through the code, there's at least two entire modules (log and fancy_getopt) that should be removed in favour of the new logging and optparse modules. Obviously this isn't possible if 1.5.2 compatibility is to be kept.
Last time we discussed this the conclusion was that 1.5.2 compatibility is needed for 2.3 and we can then move on to 2.0 compatibility for 2.4.
Or should they be replaced with copies of the logging and optparse modules in the distutils CVS tree?
Not for 2.3, but perhaps for 2.4 if those modules are 2.0 compatible. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 14 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
EuroPython 2003, Charleroi, Belgium: 41 days left
On Wed, May 14, 2003 at 09:47:19AM +0200, M.-A. Lemburg wrote:
Last time we discussed this the conclusion was that 1.5.2 compatibility is needed for 2.3 and we can then move on to 2.0 compatibility for 2.4.
Why 2.0- and not 2.2-compatible? 2.2 is the version the PBF is concentrating on; are 2.0/2.1 of much interest to customers? --amk
Andrew Kuchling wrote:
On Wed, May 14, 2003 at 09:47:19AM +0200, M.-A. Lemburg wrote:
Last time we discussed this the conclusion was that 1.5.2 compatibility is needed for 2.3 and we can then move on to 2.0 compatibility for 2.4.
Why 2.0- and not 2.2-compatible? 2.2 is the version the PBF is concentrating on; are 2.0/2.1 of much interest to customers?
I'm not talking about customers or the PBF. If you're starting to go for Python 2.2 in distutils, then it'll become very hard for code publishers to provide Python 2.0/2.1 versions of their code and, yes, these version are still in use out there. Besides, I don't think that distutils really needs any of the features in versions later than Python 2.0. The only reason I see for moving to later version would be the integration or use of Python std lib modules from later Python versions. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 14 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
EuroPython 2003, Charleroi, Belgium: 41 days left
M.-A. Lemburg wrote:
If you're starting to go for Python 2.2 in distutils, then it'll become very hard for code publishers to provide Python 2.0/2.1 versions of their code and, yes, these version are still in use out there.
fwiw, 2.1 accounts for about 20% of the PIL 1.1.4 downloads. </F>
On Wed, May 14, 2003 at 04:22:25PM +0200, M.-A. Lemburg wrote:
If you're starting to go for Python 2.2 in distutils, then it'll become very hard for code publishers to provide Python 2.0/2.1 versions of their code and, yes, these version are still in use out there.
I don't follow this. Publishers write a setup.py against the Distutils API; this has to run on the Python version being used. In implementing the API, the Distutils code can use 2.2 or not, but that's irrelevant to publishers as long as the installed version of Distutils actually runs.
features in versions later than Python 2.0. The only reason I see for moving to later version would be the integration or use of Python std lib modules from later Python versions.
... which is in fact what Anthony was wondering about. Both logging and optparse/Optik seem to be supported under 2.0/2.1, so including a copy shouldn't need any backporting; the requisite sys.path manipulations might be a bit of a pain, though. As long as we avoid generators, everything should be fine. --amk (www.amk.ca) HAMLET: There's a special providence in the fall of a sparrow. -- _Hamlet_, V, ii
Andrew Kuchling wrote:
On Wed, May 14, 2003 at 04:22:25PM +0200, M.-A. Lemburg wrote:
If you're starting to go for Python 2.2 in distutils, then it'll become very hard for code publishers to provide Python 2.0/2.1 versions of their code and, yes, these version are still in use out there.
I don't follow this. Publishers write a setup.py against the Distutils API; this has to run on the Python version being used. In implementing the API, the Distutils code can use 2.2 or not, but that's irrelevant to publishers as long as the installed version of Distutils actually runs.
Ok, let's make this clearer: it is indeed irrelevant if you're just using very simple setup.py files together with your code. These are likely to work with all distutils currently in use out there... But if you start extending distutils in various ways to better meet your requirements, then you're stuck, since you will either have to build different versions for different distutils version, add lots of if-elif-else conditional tricks or simply give up and not support older versions anymore. The problem (and at the same its strength) in distutil's design is that it is a system which provides a framework. This makes replacing parts in distutils rather hard because that would likely break existing setup.py configurations out there.
features in versions later than Python 2.0. The only reason I see for moving to later version would be the integration or use of Python std lib modules from later Python versions.
... which is in fact what Anthony was wondering about. Both logging and optparse/Optik seem to be supported under 2.0/2.1, so including a copy shouldn't need any backporting; the requisite sys.path manipulations might be a bit of a pain, though. As long as we avoid generators, everything should be fine.
The question really is: do you want to force people using older Python versions to upgrade their distutils version before installing a package or not. Given that the current distutils is so easy to use, I think that would raise the bar considerably for the casual user... unless you ship a complete copy of distutils together with your source package which is how MS does it :-/ -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, May 16 2003)
Python/Zope Products & Consulting ... http://www.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
EuroPython 2003, Charleroi, Belgium: 39 days left
On Wed, 14 May 2003 17:31:19 +1000, Anthony Baxter wrote:
new logging and optparse modules. Obviously this isn't possible if 1.5.2 compatibility is to be kept.
I don't care about 1.5.2, but about 2.2 as the current "stable" Python platform. Ciao, Jürgen -- Jürgen Hermann, Developer WEB.DE AG, http://webde-ag.de/
On Wed, May 14, 2003 at 05:31:19PM +1000, Anthony Baxter wrote:
When is it ok to lose the backward-compatibility of distutils? Going through the code, there's at least two entire modules (log and fancy_getopt) that should be removed in favour of the new logging and optparse modules. Obviously this isn't possible if 1.5.2 compatibility is to be kept.
The unknown question is if anyone has written setup.py files that depend on fancy_getopt or distutils.log. It seems unlikely, but I don't know for sure, and breaking people's setup.py files is bad. This also makes me paranoid about rearranging command classes significantly. Perhaps if the PyPI catalog gets very complete, it can be used to take a survey of setup.py and find out how often people do something fancier than just calling setup().
Or should they be replaced with copies of the logging and optparse modules in the distutils CVS tree?
Quite likely; the copies would only need to be in the CVS tree for the standalone Distutils distribution. --amk (www.amk.ca) <reading label> "The solution." Oh, my little friend, if only you were... -- The Doctor, in "Castrovalva"
Andrew Kuchling wrote The unknown question is if anyone has written setup.py files that depend on fancy_getopt or distutils.log. It seems unlikely, but I don't know for sure, and breaking people's setup.py files is bad. This also makes me paranoid about rearranging command classes significantly.
We could ask on comp.lang.python... I'll do this. "Do you know of setup.py files that are more complex than just a setup call with some usage of Extension?" I know Richard Jones has a reasonably complex setup.py for roundup; it monkeypatches DistributionMetadata and does a bunch of work to build the install list. Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Thu, May 15, 2003 at 11:26:42AM +1000, Anthony Baxter wrote:
Andrew Kuchling wrote The unknown question is if anyone has written setup.py files that depend on fancy_getopt or distutils.log. It seems unlikely, but I don't know for sure, and breaking people's setup.py files is bad. This also makes me paranoid about rearranging command classes significantly.
We could ask on comp.lang.python... I'll do this.
"Do you know of setup.py files that are more complex than just a setup call with some usage of Extension?"
I know Richard Jones has a reasonably complex setup.py for roundup; it monkeypatches DistributionMetadata and does a bunch of work to build the install list.
PyXML's setup.py does some additional command line argument processing, to check if some parts of the library should be installed or not. There's also some work for Expat handling, and some workarounds for Distutils 1.0 bugs on Windows. Some additional commands are also provided (install_data for gettext data files), and there are some extensions for bdist_wininst. http://pyxml.sf.net/ Fourthought has a huge extension of Distutils called PackageManager (more than 3500 lines of code). I don't know how deeply it relies on the core distutils. http://www.4suite.org/ -- Alexandre Fayolle LOGILAB, Paris (France). http://www.logilab.com http://www.logilab.fr http://www.logilab.org Développement logiciel avancé - Intelligence Artificielle - Formations
participants (6)
-
Alexandre Fayolle -
Andrew Kuchling -
Anthony Baxter -
Fredrik Lundh -
Juergen Hermann -
M.-A. Lemburg