patch: ez_setup.py: separate default version and minimum version of setuptools
Folks: Thank you for setuptools! We are using it in the Allmydata-Tahoe project [1]. We've patched ez_setup.py so that installation can proceed if an older version of setuptools is already present, as long as that version is not too old. This allows ez_setup.py to work seamlessly in more situations. Please apply. The patch is in-lined and attached. Regards, Zooko [1] http://allmydata.org Thu Sep 13 20:20:02 PDT 2007 zooko@zooko.com * change the 'ez_setup.py' script to have distinct desired & minimum required versions of setuptools Note that this preserves backwards compatibility -- if no minimum version is specified then the default version is used as the minimum version, which is identical to the behavior before this patch. This patch is originally due to Rob Kinninmont. diff -rN -u old-setuptools/setuptools-0.6c7/ez_setup.py new- setuptools/setuptools-0.6c7/ez_setup.py --- old-setuptools/setuptools-0.6c7/ez_setup.py 2007-09-13 20:20:58.000000000 -0700 +++ new-setuptools/setuptools-0.6c7/ez_setup.py 2007-09-13 20:20:58.000000000 -0700 @@ -61,7 +61,7 @@ def use_setuptools( version=DEFAULT_VERSION, download_base=DEFAULT_URL, to_dir=os.curdir, - download_delay=15 + download_delay=15, min_version=None ): """Automatically find/download setuptools and make it available on sys.path @@ -89,7 +89,9 @@ import pkg_resources try: - pkg_resources.require("setuptools>="+version) + if not min_version: + min_version = version + pkg_resources.require("setuptools>="+min_version) except pkg_resources.VersionConflict, e: # XXX could we install in a subprocess here? @@ -97,7 +99,7 @@ "The required version of setuptools (>=%s) is not available, and\n" "can't be installed while this script is running. Please install\n" " a more recent version first.\n\n(Currently using %r)" - ) % (version, e.args[0]) + ) % (min_version, e.args[0]) sys.exit(2) def download_setuptools(
At 11:33 PM 9/14/2007 -0700, zooko wrote:
Folks:
Thank you for setuptools! We are using it in the Allmydata-Tahoe project [1]. We've patched ez_setup.py so that installation can proceed if an older version of setuptools is already present, as long as that version is not too old. This allows ez_setup.py to work seamlessly in more situations. Please apply.
The patch is in-lined and attached.
It's not clear to me why the patch is necessary. If you reference a specific version of setuptools in your call to ez_setup(), the behavior is almost identical. The only difference is that if there is no setuptools installed, then the version you specified in your setup.py will be used for the installation.
Thank you for setuptools! We are using it in the Allmydata-Tahoe project [1]. We've patched ez_setup.py so that installation can proceed if an older version of setuptools is already present, as long as that version is not too old. This allows ez_setup.py to work seamlessly in more situations. Please apply.
It's not clear to me why the patch is necessary. If you reference a specific version of setuptools in your call to ez_setup(), the behavior is almost identical. The only difference is that if there is no setuptools installed, then the version you specified in your setup.py will be used for the installation.
The situation was that a user had a version of setuptools installed (I think it was v0.6c5), and the ez_setup.py specified setuptools v0.6c6 (which was at that time the current version). So, when the user executed "./setup.py", then he got an error saying that it wasn't possible to upgrade setuptools after setuptools was already loaded. With our patch, this is no longer a problem -- v0.6c5 is new enough to work, and so the setup.py execution proceeds after the check without attempting to install a newer version of setuptools. Regards, Zooko
At 12:56 PM 9/27/2007 -0600, zooko wrote:
Thank you for setuptools! We are using it in the Allmydata-Tahoe project [1]. We've patched ez_setup.py so that installation can proceed if an older version of setuptools is already present, as long as that version is not too old. This allows ez_setup.py to work seamlessly in more situations. Please apply.
It's not clear to me why the patch is necessary. If you reference a specific version of setuptools in your call to ez_setup(), the behavior is almost identical. The only difference is that if there is no setuptools installed, then the version you specified in your setup.py will be used for the installation.
The situation was that a user had a version of setuptools installed (I think it was v0.6c5), and the ez_setup.py specified setuptools v0.6c6 (which was at that time the current version). So, when the user executed "./setup.py", then he got an error saying that it wasn't possible to upgrade setuptools after setuptools was already loaded.
With our patch, this is no longer a problem -- v0.6c5 is new enough to work, and so the setup.py execution proceeds after the check without attempting to install a newer version of setuptools.
If you invoke 'use_setuptools("0.6c5")', you would get the same behavior with an unpatched ez_setup.py.
If you invoke 'use_setuptools("0.6c5")', you would get the same behavior with an unpatched ez_setup.py.
That's true, but the oldest version of setuptools that we support is 0.6a9, which comes with Ubuntu Dapper, but that one can't be downloaded from pypi. Therefore there is no version number that we can give to the unpatched ez_setup.py that will both allow our dapper users to run "./setup.py install" and allow users without setuptools to get it automatically installed when they run "./setup.py install". With our patch we can specify the required minimum version of setuptools (v0.6a9) separately from the default version of setuptools (v0.6c7), so that users who have setuptools can carry on as usual, and users who don't have setuptools at all get the latest version. Now, since we are using our patch we have solved this problem for our users. However, since the packages that we depend on don't use this patch, we sometimes run into the same problem. Our product -- "tahoe" -- uses simplejson, and we have a policy of managing source tarballs instead of a set of binary packages, so when we tell setuptools that tahoe depends on simplejson, then setuptools evaluates simplejson's setup.py, and then stops the build saying that simplejson requires setuptools >= v0.6c5. Our current solution to this is to ask our users to manually install simplejson. I'm hoping that a patch like the one we're offering will become widespread so that our users can get dependencies like simplejson packaged automatically. The other patch that I'm working on -- the attempt to detect setuptools version without importing setuptools -- is intended to solve a different problem that we have been faced with. That is: what happens when the version of setuptools that is already installed on the user's machine is too old -- it is known not to work -- and the user has executed "./setup.py install"? By the way, in my earlier references to pages about how we use setuptools, I forgot to include our packaging policy page: http://allmydata.org/trac/tahoe/wiki/Packaging Thank you for your time, Zooko
At 04:20 PM 9/27/2007 -0600, zooko wrote:
If you invoke 'use_setuptools("0.6c5")', you would get the same behavior with an unpatched ez_setup.py.
That's true, but the oldest version of setuptools that we support is 0.6a9, which comes with Ubuntu Dapper, but that one can't be downloaded from pypi. Therefore there is no version number that we can give to the unpatched ez_setup.py that will both allow our dapper users to run "./setup.py install" and allow users without setuptools to get it automatically installed when they run "./setup.py install".
Not so: use_setuptools("0.6a9", "http://some.where/to/download/eggs/"), where the URL is the base URL of a download location. It's true that this requires you to *have* an egg for the version in question, and make it available to download somewhere, but at that point you get a usable result.
With our patch we can specify the required minimum version of setuptools (v0.6a9) separately from the default version of setuptools (v0.6c7), so that users who have setuptools can carry on as usual, and users who don't have setuptools at all get the latest version.
Now, since we are using our patch we have solved this problem for our users. However, since the packages that we depend on don't use this patch, we sometimes run into the same problem.
It's not that they don't use the patch, it's that they don't specify the minimum version. If people supplied the minimum specified version, then the patch would be unnecessary. Conversely, having the patch will not do anything for all the packages currently distributed that don't specify a version.
The other patch that I'm working on -- the attempt to detect setuptools version without importing setuptools -- is intended to solve a different problem that we have been faced with. That is: what happens when the version of setuptools that is already installed on the user's machine is too old -- it is known not to work -- and the user has executed "./setup.py install"?
And as I mentioned on that thread, that's a lost cause if setuptools or pkg_resources are already in sys.modules by the time setup.py is executing.
Not so: use_setuptools("0.6a9", "http://some.where/to/download/ eggs/"), where the URL is the base URL of a download location. It's true that this requires you to *have* an egg for the version in question, and make it available to download somewhere, but at that point you get a usable result.
Agreed. So in order to automatically satisfy our dependency on simplejson using simplejson's source tarballs, we can either ask Bob Ippolito (the author and packager of simplejson) to please switch to the patched version of ez_setup.py and pass min_version="0.6a9" to it, or else we can ask him to please set his version="0.6a9" and start hosting setuptools 0.6a9 eggs for his users. Do I correctly understand those options? Thank you for your time. Regards, Zooko
At 01:31 PM 9/28/2007 -0600, zooko wrote:
Not so: use_setuptools("0.6a9", "http://some.where/to/download/ eggs/"), where the URL is the base URL of a download location. It's true that this requires you to *have* an egg for the version in question, and make it available to download somewhere, but at that point you get a usable result.
Agreed. So in order to automatically satisfy our dependency on simplejson using simplejson's source tarballs, we can either ask Bob Ippolito (the author and packager of simplejson) to please switch to the patched version of ez_setup.py and pass min_version="0.6a9" to it, or else we can ask him to please set his version="0.6a9" and start hosting setuptools 0.6a9 eggs for his users.
Do I correctly understand those options?
Correct. Although the hosting could certainly be shared. Personally, I have a bit of a conflict of interest in all this -- i.e., I'd much rather that people upgrade to later versions. So bear in mind that since it's already *possible* to do this, it's unlikely I'll accept a patch that makes it *easy* for people to keep using outdated alphas. :)
Agreed. So in order to automatically satisfy our dependency on simplejson using simplejson's source tarballs, we can either ask Bob Ippolito (the author and packager of simplejson) to please switch to the patched version of ez_setup.py and pass min_version="0.6a9" to it, or else we can ask him to please set his version="0.6a9" and start hosting setuptools 0.6a9 eggs for his users.
...
So bear in mind that since it's already *possible* to do this, it's unlikely I'll accept a patch that makes it *easy* for people to keep using outdated alphas. :)
Oh yes, we too prefer for our users to use newer versions of setuptools. I sympathize with your motivation. :-) Actually I think this patch makes it easier in some cases for people to gracefully upgrade to newer versions of setuptools. Consider our case: we are required to service users of Ubuntu dapper and to do so without requiring them to first upgrade their version of setuptools. If we use standard ez_setup.py, then what happens is that all of our users (not just the Ubuntu dapper using ones) get setuptools v0.6a9 installed. Eventually, our users will upgrade from Ubuntu dapper to a newer Ubuntu, and they will upgrade their version of setuptools when they upgrade their operating system, but our other users -- the ones whose version of setuptools is automatically installed by our ez_setup.py script -- will be stuck with v0.6a9. So in order to support our dapper users while also installing a newer version of setuptools for non-dapper-users, we patched our ez_setup.py. Now dapper users proceed as normal, but all our other users get setuptools v0.6c7 installed. This is already good enough for us -- we don't mind maintaining a slightly different version of ez_setup.py than the official one. The reason why this patch going into the official ez_setup.py would help us is that if packages like simplejson used it (and allowed a sufficiently old version of setuptools) then we could add simplejson to the list of dependencies that are automatically satisfied by setuptools even while satisfying the above-mentioned policies. By the way, I'm separately submitting a patch which, if it can be made to work, might allow us to automatically upgrade people to newer versions of setuptools when they follow our installation procedure. Regards, Zooko
participants (2)
-
Phillip J. Eby -
zooko