[Python-Dev] Distutils & configparser rename

[M.-A. Lemburg]

On 2008-05-15 22:33, A.M. Kuchling wrote:
> Python 2.6 renames the ConfigParser module to be configparser.
> 
> Distutils imports ConfigParser in various places.  I just made a
> commit updating the import in one places, and then noticed that part
> of commit r63248, which made the same change, was reverted in order to
> preserve backward-compatibility.  Instead, the default path will
> include lib-old again to keep the old module name available.
> 
> I suggest dropping that goal, though.  We've preserved compatibility
> but I'm not aware that anyone uses the Python 2.x Distutils with
> earlier versions of Python.  In particular:
> 
> * There's no standalone distutils package on PyPI, nor can I find
>   such a package with a general web search.  Am I missing it?
> 
> * I do not see users advising other users to use a later version of 
>   Distutils to fix their problems.
> 
> Is anyone actually benefiting from the effort of maintaining backward
> compatibility?

Yes: all the folks who want to create distutils packages for more than
just the current Python version.

I've argued for this a couple of times in the past. Some background:

In order to build a Python package for a previous Python version,
you have to run distutils using that older Python version.

Now, as distutils evolves, new features are added, bugs are fixed,
etc. so as packager you always want to use the latest distutils
version available - even with older Python releases. In some cases,
e.g. PyPI registration, this may even be necessary, since the
new versions of those commands need to be kept in sync with the
PyPI repository.

Another aspect is keeping package setup.py files working.

If you need to support multiple Python versions, then your
setup.py will have to work with multiple different versions
of distutils.

Since performance doesn't really matter for distutils, it is well
possible and easy to keep compatibility with a few releases back.

This has worked great in the past and I don't see why we should
break this, as recent distutils checkins have done.

Note that Python doesn't exactly make it easy to ship Python
packages. You have several different dimensions to take into
consideration:

  * Python version
  * UCS2/UCS4
  * Platform and processor type
  * 32/64-bit

So there already is a lot of porting effort needed to support
a reasonable number of targets.

I don't think it takes a lot of effort to keep distutils
running with Python 2.3 and 2.4.

In the past I've usually rewritten parts of distutils that
were modified in incompatible ways. I haven't been able to
that for the recent checkins that broke distutils even on
Python 2.4.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, May 16 2008)
 >>> 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,MacOSX for free ! ::::


    eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611