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
