[Distutils] easy_install and sys.path

Bryce Hendrix bhendrix at enthought.com
Wed May 9 17:30:11 CEST 2007

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.


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-',
>>> '/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  -  Distutils-SIG at python.org
>> http://mail.python.org/mailman/listinfo/distutils-sig
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/distutils-sig/attachments/20070509/f4d8d4d1/attachment.html 

More information about the Distutils-SIG mailing list