[Python-3000] Proposal: No more standard library additions

[Phillip J. Eby]

At 04:25 AM 10/14/2006 +0200, Talin <talin at acm.org> wrote:
>'Stripping' the standard library is really only a side issue for me. I
>think it would be nice if it didn't get much *bigger* - but what I
>really want most of all is for easy_install (or something like it) to
>always work, with every package. Right now, its actually easier for me
>to hunt down a Windows installer or Mac .dmg for about 50% of the
>packages than it is to install them from the command line. When I
>download something, the last thing I want to spend time doing is
>debugging its setup.py.

FYI, easy_install automatically uses distutils-built win32.exe installers 
and converts them to eggs on-the-fly when run on Windows.

With regard to how many packages can work with easy_install right now, the 
answer is tricky.  Of packages added to the Cheeseshop in the last year or 
so, probably more than 50% are easy_install-able or have eggs already 
uploaded.  However, of the extremely popular packages that have existed for 
a very long time and have their own distutils modifications or hacks (e.g. 
Twisted, PIL, pywin32, etc.) probably *more* than 50% *don't* work with 
setuptools, although many have it on their list to investigate and/or 
migrate.  It's just not a big priority for them, as they already have 
solved whatever build-and-install problems they already care about.

For Py3K, of course, there is the question of what happens to distutils and 
setuptools in the first place.  I can't imagine wanting to continue adding 
more layers of cruft and meta-cruft on them, yet can't imagine how they 
could be replaced, either.

I do, however, have my eye on Jim Fulton's zc.buildout tool, as it rather 
seems to me like it could be Python's answer to Ruby's "rake" or Java's 
"Ant".  Most of the other Python-based build tools I have seen (like SCons 
and two or three less-well-known ones whose names escape me) seem to focus 
too much on being build tools for C programs and not enough on being build 
tools.  zc.buildout on the other hand, is almost *too* flexible, but is 
much more modular, and I could see it being a lot easier to maintain e.g. C 
compiler plugins for zc.buildout than trying to keep maintaining the 
distutils' compiler framework indefinitely.

The tricky part of zc.buildout is that it depends on setuptools, at least 
to do egg downloads and installation.  However, there is some possibility 
that the dependency could be inverted, so that setuptools was built on 
zc.buildout instead of the other way around.  But these are pie-in-the-sky 
thoughts for me right now, as there's a lot still to do for Python 2.x, let 
alone thinking about Py3K.