[Python-Dev] Raising objections (original) (raw)

Phillip J. Eby pje at telecommunity.com
Wed Apr 19 21:02:15 CEST 2006

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.

More information about the Python-Dev mailing list