[Distutils] patch: ez_setup.py: separate default version and minimum version of setuptools

[Phillip J. Eby]

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.