On Mon, Nov 24, 2008 at 07:20:11PM -0500, Phillip J. Eby wrote:
At 05:46 PM 11/24/2008 -0500, Mark Sienkiewicz wrote:
As far as I can tell, the *only* purpose of __egginsert is to permit the incorrect behaviour that your patch is intended to fix.
The behavior isn't incorrect; it's by design. If you don't want that behavior, just install everything using "-m" (aka --multi-version). The eggs will then not be listed in .pth files, but any scripts installed by setuptools (including those installed via "setup.py develop") will still load the correct eggs at runtime.
For code not built with setuptools, you'll need to use pkg_resources.require() to add the eggs to sys.path dynamically.
Right, setuptools breaks standard Python behavior of a fundamental feature without giving a strong warning and forces people to monkey patch sys.path (which, as we are discussing here, as huge consequences on import semantics). No wonder system administrators (and packagers, which work with them) hate setuptools: it breaks expectation of people, and forces them to learn advanced and specific details of the Python language, which is fairly irrelevant to their work. Moreover, not respecting environment variables is a violation of all Unix good-pratices rules.
Please note that I've rejected Zooko's patch, because it makes it impossible to ensure that an easy_install-ed package takes precedence over an existing, distutils-installed version of the same package in the same PYTHONPATH directory. This is the intended default behavior of easy_install; if you wish to override it, you should use --multi-version, and explicitly select the egg(s) to be added to sys.path instead.
I am not surprised you rejected it. You are not open to any suggestion, and consider only your usecases from your point of view. You act like if what setuptools does is by definition right, no matter how much people dislike these feature, and the bad reputation it has. I have sat and watched discussions on this mailing list for over a year and concluded that the project was not in a state of moving forward, and that discussions happening on this mailing list where a loss of time. I gave up and unsubscribe. The only thing that made me come back was the announcement of a fork. That fork did not go anywhere. I think I should unsubscribe again, because all this mailing list will do is increase my frustration. Setuptools could be a very important piece of software for the future Python. It has some _very_ nice features. Your unwillingness to accept its limitations and fix the problems people are having is sacrificing its future. And yes, I am bitter. Gaël