[Distutils] easy_install and sys.path
b.n.lawrence at rl.ac.uk
Wed May 9 09:25:39 CEST 2007
Oh I know I shouldn't mix two pythons, but I've never had them "mixed" before.
(We have run our own python in /usr/local for yonks without any bad karma
until now). It's only the advent of eggs, which push things to the top of
sys.path that causes a problem. It would appear that I'm not the only person
who has the problem (e.g. see
So, my question to this list is "why"?
Why does easy_install put things in the front of sys.path? Presumably there is
some good reason (perhaps it is the only way to ensure that your dependency
libraries are the ones that are picked up, I guess there is a risk that older
libraries might exist ... but it causes problems for the reasons that Dave
Kuhlman lists in his page linked above ).
It would appear that there is fairly long established python behaviour
that "new" libraries go after "old" libraries, which easy_install has broken.
At this stage, all I want to do is understand why easy_install chose to do
I've been a big fan of eggs, but I've just slammed into a wall. I can't
believe that I'm the only one for whom this may be a problem. I now need to
work out what, if anything, I need to do about it (change my behaviour, find
out something I didn't know about egg installation, provide a suggested
optional change to egg behaviour, go home have a drink etc ...)
On Tuesday 08 May 2007 17:20:45 Tres Seaver wrote:
> Bryan Lawrence wrote:
> > Can anyone point me to why easy_install forces modules to the front
> > of sys.path? It seems to break long established rules about ordering
> > of path variables, and certainly breaks python in some unexpected
> > contexts e.g:
> > https://bugs.launchpad.net/ubuntu/+source/kubuntu-meta/+bug/113298
> In your case, you have libraries mixed from two different version s of
> python. From that launchpad issue:
> > ok, and quite clearly my path has all the /usr/local stuff in it first:
> >>>> import sys
> >>>> print sys.path
> > ['',
> '/usr/lib/python25.zip', '/usr/lib/python2.5',
> '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk',
> '/usr/lib/python2.5/site-packages', '/var/lib/python-support/python2.5']
> AFAIK, This can only happen because you have a .pth file in some 'site'
> directory which is mistakenly pulling in the "alien" eggs, which should
> never happen. *None* of those eggs are guaranteed to work in a
> different Python than the one which built them; in your case, the UCS2
> vs. UCS4 bit is interfering, but it could equally well be a different
> dynload problem.
> If you run with 'site' stuff disabled, is your sys path free of those
> eggs? E.g.:
> $ /usr/bin/python -S
> If so, find the errant .pth file and remove it (or fix the paths in it).
More information about the Distutils-SIG