Contact Us
24/7
Python BlogDjango BlogSearch for Kubernetes Big DataSearch for Kubernetes AWS BlogCloud Services

Blog

<< ALL BLOG POSTS

Bootstrapping Buildout Killing PYTHONPATH

|
October 21, 2010

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.

How can we assist you in reaching your objectives?
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.