[Distutils] easy_install and sys.path

[Bryan Lawrence]

Hi Tres

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 
http://www.rexx.com/~dkuhlman/python_comments.html).

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 
that.

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 ...)

Cheers
Bryan

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/local/lib/python2.5/site-packages/simplejson-1.4-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/Amara-1.1.9-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/flup-0.5-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/scgi-1.12-py2.5-linux-i686.egg',
> '/usr/local/lib/python2.5/site-packages/Paste-1.0-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/ZSI-2.0.dev_r1293-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/dap-2.2.5.1-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/httplib2-0.2.0-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/Cheetah-2.0rc7-py2.5-linux-i686.egg
>',
> '/usr/local/lib/python2.5/site-packages/dap.plugins.grads-0.1.1-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/arrayterator-0.2.5-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/PasteDeploy-1.0-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/PasteScript-1.0-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/dap.plugins.netcdf-0.3.2-py2.5.egg'
>, '/usr/local/lib/python2.5/site-packages/pupynere-0.2.1-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/wsgistate-0.4-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/SQLAlchemy-0.3.3-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/WSGIUtils-0.7-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/setuptools-0.6c5-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/kid-0.9.5-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/PyOpenGL-3.0.0a5-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/Genshi-0.4-py2.5.egg',
> '/usr/local/lib/python2.5/site-packages/wsgilog-0.1-py2.5.egg',
> '/usr/lib/python25.zip', '/usr/lib/python2.5',
> '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk',
> '/usr/lib/python2.5/lib-dynload',
> '/usr/local/lib/python2.5/site-packages',
> '/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).
>
>
> Tres.