We have been experimenting with using FreeBSD VMs for our development environment instead of relying on OS X. In the past week, we started experiencing really strange behavior with the buildouts on FreeBSD. The tables had turned so it seems, the builds on OS X are now working fine and the FreeBSD builds are failing. To add insult to injury, these issues were happening sporadically on other servers.
The main issue was that when the
collective.recipe.plonesite part ran, anything that did a
subprocess.call would fail giving an error like this:
Traceback (most recent call last):
File "/usr/home/clayton/projects/my-buildout/bin/instance", line 200, in ?
File "/usr/home/clayton/projects/my-buildout/eggs/plone.recipe.zope2instance-3.6-py2.4.egg/plone/recipe/zope2instance/__init__.py", line 19, in ?
ImportError: No module named recipe.egg
I was finally able to reproduce the error along side a working copy of the same buildout. After having read about the
PYTHONPATH changes in the latest version of buildout, I decided to diff the
bin directory of the two instances. The diff of the buildout executable was particularly interesting.
--- old-buildout 2010-10-20 17:08:25.000000000 -0400
+++ new-buildout 2010-10-20 17:07:43.000000000 -0400
@@ -1,10 +1,18 @@
sys.path[0:0] = [
+path = sys.path
+ path = os.pathsep.join([path, os.environ['PYTHONPATH']])
+os.environ['BUILDOUT_ORIGINAL_PYTHONPATH'] = os.environ.get('PYTHONPATH', '')
+os.environ['PYTHONPATH'] = path
+import site # imports custom buildout-generated site.py
You can see that the newly bootstrapped buildout has all the new
PYTHONPATH setup in it. The workaround for this issue is to simply use the
bootstrap.py -v option introduced in 1.3.0. Here is the command that allows our buildouts to run fine again:
$ cd path/to/buildout
$ python2.4 bootstrap.py -v 1.4.3
After doing that, the buildout gets the proper executable set up and runs fine.