[Distutils] Moving distutils minimum required version to 2.3

Anthony Baxter anthony at interlink.com.au
Wed Jun 22 15:52:44 CEST 2005

On Tuesday 21 June 2005 18:01, M.-A. Lemburg wrote:
> That's not really the point: the reason we keep the compatibility
> to Python 2.1 is that package builders and users building
> the packages themselves will want to create builds for
> various Python versions, so that need a distutils version
> that works with mutiple recent Python versions.

I'm not planning on _breaking_ compatibility at the language level,
but to depend on stuff that's in the std lib in newer versions.
Existing versions will still work fine, if you have the backported
extensions - and in any case, someone could ship a version 
that bundled up textwrap, optparse and logging, and whatever else 
was needed with the newer code (since that's the main thing I'd be 
looking to change).

The rationale for this change is this:

  Distutils has problems. Part of the reason nobody wants to touch
  it is that it's really quite complicated code - and part of the reason
  for _that_ is that it re-implements a huge amount of stuff that's now 
  part of the std library. At some point, we either need to 
  - Clean up the code so people can work on it without having their
    brain leak out the ears, or
  - Start an entirely new replacement for distutils (distutils2?) 

The former is a whole lot less work. "It's fine, and should 
remain as it is for ever and ever" is not a an outcome I'd like to see. 

> If you now jump to Python 2.3 as requirement, package
> authors will have to adapt their setup.py and associated
> distutils files to work with yet another variation of
> backend system. This is bound to break the simple install
> instructions of "python setup.py install" one way or
> another.

I don't see how this be the result. 

> It will also not be possible to use new developments in
> distutils for packages targetted for Python versions prior
> to Python 2.3 and - because distutils is normally extended
> via subclassing - make it harder to have setup.pys which
> work across multiple Python versions.

Again, I'm _not_ planning to break code. I'm planning to make
the code easier to work on -- so that hopefully, going forward,
we can get people working on distutils to improve it, rather 
than everyone writing enormously complicated setup.py scripts
that are just working around basic flaws in the current code. 

As an example: distutils' current option parsing code (fancy_getopt)
behaves quite differently to both optparse and getopt. I don't see
how this could be considered a good thing. 

> I'd suggest to have distutils use the new tools from Python
> 2.3 if available, but still continue to ship its own versions
> for Python versions prior to 2.3.

And suddenly the distutils code is even _more_ complex than it
is now! Making it use _either_ distutils.log or logging does 
not make the code cleaner, or easier to work with. 

Anthony Baxter     <anthony at interlink.com.au>
It's never too late to have a happy childhood.

More information about the Distutils-SIG mailing list