[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 01:29 PM 9/27/2007 -0600, zooko wrote:
> > 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?
>
>Oh, perhaps this also explains why you didn't understand the use case
>for the previous patch.  I love easy_install, in some cases we and
>our users need to execute "setup.py install" instead.

Unless you are using --root or --single-version-externally-managed, 
there is actually no difference: "setup.py install" actually invokes 
the rough equivalent of "easy_install .".


>   There are a
>few different reasons for this that I would be happy to go over with
>you, but hopefully as far as patching ez_setup.py, if I can write
>patches which improve this use case without harming other use cases,
>you will accept that some people prefer to execute "./setup.py
>install" and not "easy_install"?

The only reason (besides habit) to do that is to do a single-version 
installation -- in which case trying to make ez_setup do the right 
thing is a red herring.  To do a single-version install you have to 
either know precisely what you're doing, or else you're building a 
system package -- in which case you'd darn well better have a 
compatible setuptools installed.

To put it another way, I'm not interested in making it easier for 
people to shoot themselves in the foot.  The error message is there 
for good reasons, and I've thought long and hard about ways to get 
rid of it.  I'm willing to listen to new ideas, I just don't think a 
safe solution for upgrading setuptools in-place is possible without 
either multiple processes or multiple interpreters in a single process.