Re: [Distutils] easy_install and sys.path

Wed, 09 May 2007 08:31:05 -0700

Bryan still raises a valid question. The fact that setuptools shoves the eggs to the front of sys.path continues to cause false bug reports to be filed by our customers also regularly. 

Bryce

Matt Good wrote:
You seem to have missed the main point of Tres's email. The problem is not inherent to Eggs, but you seem to have either set PYTHONPATH or have a .pth file that's being loaded which is telling your /usr Python to look in the /usr/local Python's site-packages folder. Packages installed to /usr/local in the traditional way would still be on sys.path and would have the exact same problem. So check your PYTHONPATH and grep your .pth files in /usr/lib/python2.5/site-packages for any references to /usr/local and remove them. 

-- Matt Good

Bryan Lawrence wrote:

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.

_______________________________________________
Distutils-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig


_______________________________________________
Distutils-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig




_______________________________________________
Distutils-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/distutils-sig

Reply via email to