Andi Vajda <va...@apache.org> wrote: > Bill, could you please expand a bit on that red flag you just alluded > to for those of us who don't follow the distutils list.
The big problem with setuptools is that it's a widely ambitious package with featuritis and I-know-better-itis, maintained from a private codebase by an apparently talented guy who has for a while now apparently has not had the time to fix its multiple and manifest bugs. It hooks into seemingly everything, and causes weird and wonderful install and execute problems. The inability to rectify the outstanding issues has caused some other folks to now fork it... It's a mess. For example, when I tried to auto-build UpLib and all of its dependencies on a new Ubuntu machine this morning, I had to stop in the middle and *manually* apply, guess what, a setuptools patch, to get pylucene to build. Everything else worked fine. It's polluted the distutils space, and PyPI. I no longer trust "python setup.py install" to do the right thing, because who knows if the package author thought that using setuptools was a wonderful idea? Instead, I drop a standardized Makefile into the top level of the unpacked package, and "make install DESTDIR=foo" simply bundles up the built extension, and then unpacks it in the right place under "foo". No potential easy-install.pth to deal with, no oddball installation prefixes under OS X (which seems to think that /Library/Python/2.x/site-packages is the only place to put extensions, and, to be fair, that's not a setuptools issue -- I think), no arguing with setuptools about whether or not that target directory will be reachable by my application, no inability to control sys.path, etc. Bill
