[Python-3000] Proposal: No more standard library additions
Phillip J. Eby
pje at telecommunity.com
Sat Oct 14 05:34:00 CEST 2006
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.
More information about the Python-3000