[Distutils] Re: [Python-checkins] python/dist/src/Lib/distutils sysconfig.py,1.52,1.53

[M.-A. Lemburg]

Jeremy Hylton wrote:
>>>>>>"MAL" == mal  <M.-A.> writes:
> 
> 
>   >> Python 1.5.2 users have been running with distutils 1.0.2 for
>   >> about a year and a half now.  We haven't heard any complaints
>   >> from them about the lack of releases for 1.5.2.
> 
>   MAL> Maybe that's because package developers have tried to keep
>   MAL> 1.5.2 compatibility by adding bug fixes to their setup.pys ?!
>   MAL> I know that I've done this in the past.
> 
> Examples, please.  I don't maintain any software that is intended to
> run with 1.5.2, so I can't quite imagine what you mean.

Here's one:

         # We set these here, since distutils 1.0.2 introduced a
         # new incompatible way to process .define and .undef
         if build_ext.define:
             #print repr(build_ext.define)
             if type(build_ext.define) is types.StringType:
                 # distutils < 1.0.2 needs this:
                 l = string.split(build_ext.define, ',')
                 build_ext.define = map(lambda symbol: (symbol, '1'), l)
             build_ext.define = build_ext.define + define
         else:
             build_ext.define = define

>   >> I believe the last release was good enough for 1.5.2.  If someone
>   >> can live with all the bugs and out-of-date stuff in 1.5.2, they
>   >> can live with a slightly out-of-date distutils, too.
> 
>   MAL> If they won't be able to compile distutils packages anymore,
>   MAL> they certainly won't feel good about it.
> 
> I don't think anyone has suggested making changes such that would
> prevent people from building distutils packages.  I just don't
> understand the fear here.

I am talking about users who want to build from source. Your
changes, even though just cosmetic, prevent compatibility with
Python 1.5.2, so these users will no longer have a chance to
update to the latest distutils version.

As a result, packagers who want to maintain Python 1.5.2
compatibility will have to start maintaining setup.pys for
various distutils versions out there and that's a pain (it
already is a pain having to maintain this compatibility for
the many Python versions out there).

>   >> It's a pain in the neck to hack on distutils and be careful to
>   >> avoid accidentally adding code that won't work with 1.5.2.
> 
>   MAL> Huh ? Avoiding string methods isn't all that hard.
> 
> In large software projects like Zope and Mailman, people have
> repeatedly run into problems with Python version compatibility.  There
> are lots of differences between 1.5.2 and 2.2.2, and it is easy to use
> a new feature without thinking "I'm using a new feature."

We have PEPs for this:

	http://www.python.org/peps/pep-0291.html
	http://www.python.org/peps/pep-0290.html

It's really not that hard to not use the latest features
in coding Python. None of the new hip features are necessary
for distutils' application scope.

>   MAL> Instead of discussing code cosmetics we should look into adding
>   MAL> more packagers for e.g. debian and freebsd. These things are
>   MAL> much more important, IMHO.
> 
> They haven't proven important enough for anyone to do anything about
> them <0.3 wink>.

That is not entirely true. There was an effort to standarize
binary packagers and add more support for Solaris and HP-UX.
Unfortunately, we had to pull the support from CVS due to
copyright issues.

I am repeating myself here, but I still don't understand where
the motivation to break distutils on Python 1.5.2 stems from.

-- 
Marc-Andre Lemburg
CEO eGenix.com Software GmbH
_______________________________________________________________________
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/