[Python-Dev] magic in setuptools (Was: setuptools in the stdlib)

Phillip J. Eby pje at telecommunity.com
Fri Apr 21 01:31:36 CEST 2006


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.




More information about the Python-Dev mailing list