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!).