Re: why not setuptools?
On Oct 15, 2009, at 9:42, Bill Janssen wrote: Felix Schwarz wrote: Am 15.10.2009 07:01, schrieb Andi Vajda: If distutils or the new fork grows the ability to build a regular shared library, I'd be less wedded to setuptools. Maybe you want to contact the distribute guys which is a setuptools fork. I know that some Linux distributions are using distribute already as a drop-in replacement for setuptools (Fedora Linux will switch to distribute for F13 very likely). This seems to me to simply be going further down the wrong path that setuptools initiated. The right thing to do (purely IMO) is to fix distutils to add the functionality needed. There lies the rub. Why isn't that happening, though ? Andi.. Bill
Re: why not setuptools?
Felix Schwarz wrote: > Am 15.10.2009 07:01, schrieb Andi Vajda: > > If distutils or the new fork grows the ability to build a regular shared > > library, I'd be less wedded to setuptools. > > Maybe you want to contact the distribute guys which is a setuptools > fork. I know that some Linux distributions are using distribute > already as a drop-in replacement for setuptools (Fedora Linux will > switch to distribute for F13 very likely). This seems to me to simply be going further down the wrong path that setuptools initiated. The right thing to do (purely IMO) is to fix distutils to add the functionality needed. Bill
Re: why not setuptools?
Am 15.10.2009 07:01, schrieb Andi Vajda: If distutils or the new fork grows the ability to build a regular shared library, I'd be less wedded to setuptools. Maybe you want to contact the distribute guys which is a setuptools fork. I know that some Linux distributions are using distribute already as a drop-in replacement for setuptools (Fedora Linux will switch to distribute for F13 very likely). fs
Re: why not setuptools?
On Wed, 14 Oct 2009, Bill Janssen wrote: Andi Vajda 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..
why not setuptools?
Andi Vajda 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
