[Distutils] patch: solving the two major things that people dislike about setuptools, part 1

[Gael Varoquaux]

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