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 ?
import plone.recipe.zope2instance.ctl
File "/usr/home/clayton/projects/my-buildout/eggs/plone.recipe.zope2instance-3.6-py2.4.egg/plone/recipe/zope2instance/__init__.py", line 19, in ?
import zc.recipe.egg
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 @@
-#!/usr/local/bin/python2.4
+#!/usr/local/bin/python2.4 -S
import sys
sys.path[0:0] = [
- '/usr/home/clayton/.buildout/eggs/setuptools-0.6c11-py2.4.egg',
- '/usr/home/clayton/.buildout/eggs/zc.buildout-1.4.3-py2.4.egg',
- ]
+ '/usr/home/clayton/sixfeetup/projects/sixfeetup/sfupsite-buildout/parts/buildout',
+ ]
+
+
+import os
+path = sys.path[0]
+if os.environ.get('PYTHONPATH'):
+ 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
import zc.buildout.buildout
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.