zooko <zooko@zooko.com> writes:
1. Should the act of "easy_install foodistribution" cause subsequent "python -c 'import foomodule'" to get the new, easy-installed foo, instead of the pre-existing, distutils-installed foo which is in the system directory?
By the defined behaviour of PYTHONPATH and sys.path, the answer to this would be “that depends on where ‘easy_install foodistribution’ installed the distribution”. If ‘easy_install’ wasn't explicitly instructed to install somewhere other than the system directory, then it should behave like distutils in this respect and *replace* the existing instance in the system directory. In other words, by default setuptools should be installing distributions in the same place as distutils. If ‘easy_install’ has been configured to put things in a different place, then at import time the rules of PYTHONPATH and sys.path apply — and setuptools should leave those alone so the user has the behaviour promised in the documentation for PYTHONPATH and sys.path.
PJE has already made clear (see references on the ticket that I filed or in my earlier mail) that he wants the answer to 1 to be "yes", because he is supporting a common use case in which a user doesn't know how to uninstall the old foo but wants to use easy_install to get a new foo.
If the argument is that this “common use case” involves ignoring, overriding, or munging the existing PYTHONPATH or sys.path, that's a bad argument. The way to change that behaviour is *not* to have magic special behaviour in setuptools; it's to change the way Python works so this use case is supported, if you can convince the Python team to do so. Special cases aren't special enough to break the rules. This smells very much like a special case, and it's entirely possible to support it with the existing PYTHONPATH and sys.path behaviour, AFAICT. -- \ “It is hard to believe that a man is telling the truth when you | `\ know that you would lie if you were in his place.” —Henry L. | _o__) Mencken | Ben Finney