[Distutils] backwards compatibility of distutils?

[M.-A. Lemburg]

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