buildout uses sys.path, not PYTHONHOME to insert libraries. means subprocesses fail, or use wrong libs.

[illume]

The test and pythons created by buildout do not use PYTHONHOME to insert the egg paths, but instead hack sys.path.

This is ok if the pythons do not call other processes... but if they do, the libs used will be wrong (probably will use system libs).

A work around is to create a PYTHONHOME from the sys.path to pass to sub processes. However, maybe just setting the PYTHONHOME in the bin/python and bin/test etc would be better and more reliable.

[claytron (clayton-sixfeetup)]

I started running into this issue with the 1.5.x bootstrapping process on FreeBSD (doesn't seem to affect OS X). When I bootstrap a project using 1.4.3, the files get written out using the new 1.5.x process. I ran into the above mentioned issue when a recipe does a subprocess.call that in turns calls python code expecting to have the proper PYTHONPATH setup.

I had to temporarily fix a recipe that I wrote to insert the proper path as follows:

http://dev.plone.org/collective/changeset/145988/buildout/collective.recipe.plonesite/trunk

I did a write up about this on my company blog:

http://www.sixfeetup.com/blog/bootstrapping-buildout-killing-pythonpath