[Distutils] shebang line modified by setuptools

[Phillip J. Eby]

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.