At 04:25 AM 10/14/2006 +0200, Talin <[EMAIL PROTECTED]> 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. _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
