system installed eggs overriding buildout provided packages

So this isn't actually a problem, because our scripts all do 'import _pythonpath' which resets the path correctly. Well... almost all of our scripts do. Some of the scripts in database/schema are so old they don't use this mechanism and cause warnings to be raised about module conflicts.

Actually, the _pythonpath kludge isn't a solution. The fact that bin/py and bin/test have wrong paths is causing many other problems. Especially, it prevented Leonard from adding a merge target for launchpadlib because the tests would always be run from the system launchpadlib.

I think we can use the PYTHONSTARTUP environment variable to rewrite the path so the buildout installed libraries come before the system libraries.

We now have a branch (sitepackages-ng-1) merged that addresses the concerns Francis raises in comment #2. With that branch, when I compare the sys.path for bin/py and bin/harness, I get different order for the paths, but the exact same eggs in a set comparison.

I tried the PYTHONSTARTUP approach that Stuart suggested. This works well for running bin/py in the interactive prompt but PYTHONSTARTUP has no affect on using bin/py to run scripts (it is described in ``python -h`` as "PYTHONSTARTUP: file executed on interactive startup (no default)"). Therefore it does not work for all of our use cases.

I'm going to optimistically declare this fixed via my buildout branch, and stick with the use of PYTHONPATH.

If we have further problems with bin/py, we can investigate using the Python-interpreter-alike that zc.recipe.egg can produce. It does not and cannot support all of the options that the normal Python binary offers, and we use some of them in the Makefile, so it might need some care in the switch.

I'm seeing this again:

$ bin/py
Python 2.5.5 (r255:77872, Jan 31 2010, 21:34:29)
[GCC 4.4.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pytz
>>> pytz.__version__
'2009e'
>>> import sys
>>> sys.path
['', '/usr/lib/python2.5/site-packages/pytz-2009e-py2.5.egg', '/home/stub/lp/trivial/parts/scripts', '/usr/lib/python2.5', '/usr/lib/python2.5/plat-linux2', '/usr/lib/python2.5/lib-tk', '/usr/lib/python2.5/lib-dynload', '/home/stub/lp/lp-sourcedeps/eggs/setuptools-0.6c11-py2.5.egg', '/home/stub/lp/trivial/lib', '/home/stub/lp/lp-sourcedeps/eggs/windmill-1.3beta3_lp_r1440-py2.5.egg', '/home/stub/lp/lp-sourcedeps/eggs/funkload-1.10.0-py2.5.egg', '/home/stub/lp/lp-sourcedeps/eggs/zc.zservertracelog-1.1.5-py2.5.egg', '/home/stub/lp/lp-sourcedeps/eggs/zope.server-3.6.1-py2.5.egg'

1) I'm guessing this is Karmic? I can't install pytz on Lucid, for some reason, so I can't dupe.
2) Did this only start to happen after you installed distribute (bug 564680)? I haven't tried that yet.
3) Was this true after a fresh build, or a make clean && make?
4) Could you attach your bin/py and your parts/scripts/site.py?

This was Jaunty.

I do not know if this was happening before installing distribute.

This was true after a make clean & make.

bin/py and parts/scripts/site.py won't be available until next week.

Argh.... Lucid.... I meant this was Lucid.

I was able to duplicate. This is a new bug having to do with Distribute support. I opened bug 568486, and have a branch with a fix but no automated tests yet (which will be a bit annoying to write). I'm closing this bug again.