On Wed, 14 Oct 2009, Bill Janssen wrote:
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.
Yeah, I hear you loud and clear. And yet, it's an improvement over
distutils.
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.
And I went through quite a bit of girations to automate that in JCC's
setup.py :)
I filed this bug a year ago now.
PJE, the disutils author, said: "just copy the classes you patched into your
own fork of setuptools and ship that". Oh well.
If distutils or the new fork grows the ability to build a regular shared
library, I'd be less wedded to setuptools.
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.
I've recently started using virtualenv.py and it's simply wonderful. All
these strange things one has to do to install Python software can now be
ignored. You just use and abuse your scratch python's site-packages with
whatever you want.
I wish this had existed when we were building Chandler at OSAF.
Andi..
