[Python-Dev] Raising objections

[Phillip J. Eby]

At 07:46 PM 4/19/2006 +0200, Martin v. Löwis wrote:
>Greg Ewing wrote:
> >> I started refactoring some of the ugliness out of the internals of
> >> distutils last year, but was completely stymied by the demand that no
> >> existing setup.py scripts be broken.
> >
> > Instead of trying to fix distutils, maybe it would be better
> > to start afresh with a new package and a new name, then
> > there wouldn't be any backwards-compatibility issues to
> > hold it back.
>
>It is *precisely* my concern that this happens. For whatever reason,
>writing packaging-and-deployment software is totally unsexy.

I can tell you the reasons, no need to guess:

1. It's bloody hard work.  Honestly, if I really knew what I was in for by 
doing this, I might not have started.  That doesn't mean I'm going to 
*stop*, just that I'd have thought twice before starting.

2. Everybody thinks they can do it better, and isn't afraid to tell you so.

3. People complain that things didn't magically work the way they expected, 
but rarely provide any information about what they did or didn't do or how 
they think it should've figured out what they mean.

4. When it works, nobody notices or cares.  When it doesn't work *once*, 
people blog that it's crap and should never be used -- but don't report the 
problem or ask for help, and don't change their judgment of "crap" even if 
the problem is fixed in a few days through somebody sending me mail about 
the blog article.


>  If distutils is now abandoned and replaced with
>something else, the same story will happen again: the developers will
>run away, the package gets abandoned, and, after a few years of sadness,
>a new, smart developer will come along and provide a super replacement.
>And that will repeat in cycles of roughly 10 years.
>
>We have to stop this. If distutils has flaws, fix them.

I agree with you, which is why setuptools fixes distutils' flaws by 
subclassing where possible and monkeypatching only where necessary to 
ensure compatibility.  (Only three classes are monkeypatched: Distribution, 
Command, and Extension.)

It would be better to simply integrate those changes into the distutils in 
the long run, rather than maintaining two layers.  The problem in the short 
term, however, is backward compatibility: sometimes people are relying on 
internals or implementation details of the existing distutils.

I would suggest that setuptools be considered "distutils2" for all 
practical purposes, with the intention of being merged into the distutils 
proper for Py3K.  Whether setuptools gets included in Python 2.5 or not, it 
should be in *some* 2.x release, and merge fully in 3.x.