[Distutils] patches: ez_setup.py: don't import setuptools into your current address space in order to learn its version number

[Phillip J. Eby]

At 03:29 PM 9/18/2007 -0600, zooko wrote:
>Folks:
>
>We're gradually converting the allmydata.org tahoe project [1] and
>its spin-off packages to use setuptools.  One problem that comes up
>is that ez_setup.py might require a newer version of setuptools than
>the version of setuptools already installed.
>
>For example, although Tahoe currently uses setuptools to manage its
>dependencies on zfec, foolscap, and nevow [2], but if we execute
>simplejson's ez_setup.py then it requires setuptools v0.6c7 and
>refuses to proceed if an earlier version is installed.
>
>One solution for this problem could be for the packager of simplejson
>(Bob Ippolito) to use the "min_version" patch that we contributed to
>ez_setup.py [3].  This is assuming that simplejson doesn't actually
>*require* the latest version of setuptools, and we could successfully
>install with a slightly older version, but what if a package actually
>does require a newer version of setuptools than the one that is
>already installed?
>
>The following patch was created by Tahoe contributor Arno Washck and
>then modified by me in order to get around such a problem.  The idea
>is simple enough -- reload setuptools.  There may be some subtleties
>that we still need to work out.  This patch hasn't been tested in its
>current form.

It won't work correctly.  First, pkg_resources is part of setuptools, 
so if you install a new version of setuptools, you have to reload() it too.

Second, it's not *safe* to reload it, if it or setuptools were 
already imported at the time the function is called.  That's because 
easy_install runs the setup.py of a package it's building from 
source.  So if you use easy_install to install a package that needs a 
newer version, reloading pkg_resources or setuptools (and note that 
setuptools is a package with lots of submodules!) will break the host 
easy_install process.

Basically, that's why ez_setup.py is written the way it is.  The best 
case scenario here would be to check if setuptools or pkg_resources 
are already imported, and if not, then the pkg_resources version 
check + reload of pkg_resources would work.

But if they are already imported, there is no way to reload them in a 
way that won't hose something that's already in progress in the 
caller's context.

In other words, we could maybe fix this for "setup.py install", but 
not for easy_install.  I'm not sure how useful that is, though, since 
if you have setuptools installed, why download "foo", unpack it, and 
"setup.py install", when you can just "easy_install foo" in one go?

About the only thing that *might* work would be to have easy_install 
detect the error when trying to build the package, and then download 
a new setuptools and run the setup.py in a subprocess with that 
setuptools on the path, and finish up the current install by 
switching to the new setuptools.

But that's just insane, because what if the user is running e.g., 
easy_install -zmaxd to build a collection of eggs for 
distribution?  It makes no sense to install the new setuptools in the 
*distribution* directory.

So, unfortunately, the end user is the only one who can safely 
upgrade their setuptools version (especially if they're doing it via 
.rpm or .deb or some such!).