[Distutils] patches: ez_setup.py: don't import setuptools into your current address space in order to learn its version number
Phillip J. Eby
pje at telecommunity.com
Thu Sep 27 18:51:27 CEST 2007
At 03:29 PM 9/18/2007 -0600, zooko wrote:
>We're gradually converting the allmydata.org tahoe project  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 , 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 . 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
>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
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
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
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
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!).
More information about the Distutils-SIG