[Python-Dev] magic in setuptools (Was: setuptools in the stdlib) (original) (raw)
Phillip J. Eby pje at telecommunity.com
Fri Apr 21 01:31:36 CEST 2006
- Previous message: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
- Next message: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 12:32 AM 4/21/2006 +0200, M.-A. Lemburg wrote:
Phillip J. Eby wrote: > What I'm opposed to in making setuptools install things the distutils way > by default is that there is no easy path to clean upgrade or installation > in the absence of a system packaging tool like RPM or deb or > what-have-you. I am not opposed to doing the "classic" style of > installation by default forever, but only until setuptools can handle > uninstallation and upgrades in that format. Right now, it's a lot easier > to uninstall things if they are all in one directory.
If that's all it takes, have a look at the uninstall implementation in mxSetup.py (e.g. from egenix-mx-base).
I have. As far as I can tell, it requires you to save the original setup.py, and for any dynamic considerations of that setup.py to still be in effect. What's actually needed is to save the list of outputs at installation time, so it's not practical to use your implementation for setuptools' purposes. I thought I'd explained this when you suggested this on the distutils-sig previously, but perhaps I forgot to.
As well, there's another consideration for easy_install, which "virtualizes" the installation process for packages that don't use setuptools. Such packages may have customized their installation process by extending the distutils, without overriding get_outputs(). Since few people actually use the --record option for anything important, nobody notices when it breaks. It's often hard to implement correctly in the first place, so this is probably why most tools that wrap distutils prefer to use --root instead of --record anyway... which means that there's even less incentive to write correct get_outputs() methods.
BTW, if there's interest, I can look into porting the stuff in mxSetup.py into stock distutils. That'll give it uninstall, some autoconf and support for building Unix C libs as part of the process (plus a bunch of other things).
I imagine quite a lot of those things would be useful, except that I have personally noticed some issues through these extensions not following distutils standards. (Oh, the irony! :))
Specifically, I have noticed that your autoconf command does not use the 'build' command as the basis for obtaining its default '--compiler', which caused me quite a bit of trouble when trying to easy_install some of your packages. At least your mx_build_ext command handles this correctly.
In general, distutils commands take their defaults from either the "build" or "install" master commands, as this allows users to have a single place to configure default options.
But I digress. I do think there are a lot of useful things in your work and it was on my list to steal as many of your ideas as possible as soon as I got to working on setuptools things that needed them. :)
I certainly wouldn't object to them being in the distutils, though I'm likely to nitpick certain little things like the aforementioned compiler defaults.
- Previous message: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
- Next message: [Python-Dev] magic in setuptools (Was: setuptools in the stdlib)
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]