[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