At 08:26 PM 4/13/2008 +0200, Gael Varoquaux wrote:
On Sun, Apr 13, 2008 at 02:04:56PM -0400, Phillip J. Eby wrote:
At 05:29 PM 4/13/2008 +0200, Gael Varoquaux wrote:
Of course setuptools will break this, because it adds itsef to front of the PYTHONPATH, and totally break the PYTHONPATH semantics (Grrr).
The entire point of PYTHONPATH is to be able to put things at the front of it, so I don't see how that's breaking anything.
Well actually, my phrasing in the above was catastrophic. I have mixed PYTHONPATH and sys.path. Anyhow, I have a problem with how setuptools deals with both:
* sys.path
When you ask easy_install to install something as the default importable version of that package, the only way to ensure that is by placing that thing at the front of sys.path, to override any other version of it that might be installed elsewhere on sys.path.
What I would want is setuptools to respect the priorities for packages depending on where they are installed. In other words, if I install a package in /usr/local/lib and this is further down the priorities than /usr/lib, then I don't expect this package to override module imports happening from /usr/lib.
And you're saying that setuptools does this? Since when? [pause to investigate] Hm... that's a bug, actually. If there are multiple 'site' directories, then what you describe will indeed happen; eggs in the later 'site' directory will indeed override those in the former, which should not happen. The issue is that the postamble of easy-install.pth is simply inserting the eggs at the head of sys.path, even in cases where they could simply be inserted immediately before the directory the .pth file is in. One minor issue, however, is that eggs in the systemwide site-packages must also be able to override the stdlib - so simply locating the correct insertion point isn't going to fix the whole problem. However, now that it's a known bug, it's merely an engineering problem to fix it. :)
With standard Python, I can override the import mechanism using the PYTHONPATH. This way I can make sure that the modules I want get imported. And pretty much all the programs I can think of with a path environment variable behave like this. Now if I have a module installed with setuptools, I no longer have the possibility to do this, because setuptools inserts it self before the PYTHONPATH.
I'm not following you here. Are you trying to specify the use of a different version of setuptools? What do you mean by "setuptools inserts itself before the PYTHONPATH"?
This second problem could probably easily be fixed, though, by some more clever monkey patching of the sys.path.
In general, setuptools' path management could be improved by tweaking its path hacks so that an egg is positioned only in front of the directory that contains it (except for lib/site-packages eggs, which need to also override lib). Patches welcome.