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.