[Python-Dev] PEP 384 accepted

Tarek Ziadé ziade.tarek at gmail.com
Thu Dec 2 23:44:57 CET 2010

2010/12/2 "Martin v. Löwis" <martin at v.loewis.de>:
>>> This freeze made the situation worse.
>> Can you extend on this and explains why it makes it worse ?
> Before the freeze, distutils was unmaintained (i.e. before you started
> maintaining it), but people who want to improve it gradually atleast
> could. Now gradual improvements are also banned, so it's not only
> unmaintained, but I can't even provide support for the PEP in Python
> that was just accepted.
>>> IIRC, it was really the incompatible changes that made people ask you to
>>> stop changing distutils.
>> Who is "people" ? Are you suggesting that we could have added all the
>> new features in Distutils in the stdlib ?
> No, only the ones that didn't cause backwards incompatibilities,
> and broke existing packages.

This is impossible. I can point you to some third party project that
can break if you touch some distutils internals, like setuptools.
Setuptools also uses some privates global variables in some other
modules in the stdlib FYI.

The right answer was maybe back then: make setuptools and other
projects evolve with distutils.

But it did not happen. So we left the status quo and moved forward in
distutils2. Because we knew distutils needed deeper changes anyways,
and we knew setuptools was used everywhere and unfortunately not
evolving at the same pace. (note: I am not blaming PJE or anyone when
I say this -- the way distutils worked and was poorly maintained was
the main reason)

>> But that's what you would expect for a project that needs to evolve a
>> lot. Thus the freezing.
> Instead of evolving a lot, and instead of freezing, I would have
> preferred "evolve a little".
>> So how would you make the situation better, if not by doing the work
>> in distutils2 ?
> Lift the freeze. I'm all for replacing distutils with distutils2, but
> I'm not sure whether you will declare distutils2 ready tomorrow, next
> year, or ten years from now.

Depends on what "ready" means.

If by ready you mean it can be used to replace Distutils1 in a
project, I declare Distutils2 ready for usage NOW.  It's in alpha
stage. I want a solid beta before Pycon.

I would even remove Distutils from 3.x altogether at some point since
setuptools is not Python 3 compatible, and just put distutils2.

3.3 sounds like a good target.


Tarek Ziadé | http://ziade.org

More information about the Python-Dev mailing list