Problem: running “python bootstrap.py” or “bin/buildout” often produces scripts that mix up the Python package search path due to some packages being installed system-wide. Version conflicts result.
Workaround: use “python -S bootstrap.py” and “python -S bin/buildout”. Magically, no more version conflicts.
I wish I had thought of that before. Duh!
Update: Another tip for new zc.buildout users I’ve been meaning to mention is that you should create a preferences file in your home directory so that downloads and eggs are cached centrally. This makes zc.buildout much friendlier. Do this:
mkdir ~/.buildout echo "[buildout]" >> ~/.buildout/default.cfg echo "eggs-directory = $HOME/.buildout/eggs" >> ~/.buildout/default.cfg echo "download-cache = $HOME/.buildout/cache" >> ~/.buildout/default.cfg
It seems a bit silly that zc.buildout doesn’t have these settings by default. They make zc.buildout behave a lot like Apache Maven, which is what a lot of Java shops are using these days. Both zc.buildout and Maven are great tools once you get to know them, but both are a real pain to understand at first.
Hello,
just wondering if you could not use virtualenv to obtain the same result.
Sure you could use virtualenv, but isn’t “-S” a lot simpler? With virtualenv there is a lot more I have to remember to do.
Another useful tip for developers:
unzip=true
that makes all eggs to be used in an unzipped form that helps when debugging
grokproject creates a .default.cfg for you automatically when you install Grok with the egg-directory in there. Not the download cache as that’s two layers of caching, and sometimes surprised us in the past when eggs had magically disappeared. Installation would work for us but nobody else.
I hadn’t heard of the python -S option; that seems to be much easier than using virtualenv to get the same effect, and I’m amazed that after so much struggles people have had with exactly that issue, Grok recommending them to install virtualenv on at least Mac OS X and such, the solution turns out to be that simple! If this works for us we’ll update the Grok documentation accordingly.
-S disables loading site.py, which does more than just add site-packages to the path. For example, on Windows it also adds aliases for some missing default encodings. IIRC, some distributions hook into site.py for adjustments as well.
Thus, disabling can have undesirable side effects. Virtualenv goes through some pains to keep the site.py script working. I’d say sticking with virtualenv is the way to go still.
Very useful info, Adam, Martijn, and Martijn. 🙂
I’m not comfortable with virtualenv in general because it seems like a complex mechanism that does nothing but fix sys.path. It seems like zc.buildout should be able to handle that responsibility without help.