AFAICT, this problem was only reported once, here: https://mail.zope.org/pipermail/zope-dev/2012-February/044108.html but nobody identified the cause or steps to reproduce. What I've figured out is this: if your buildout's absolute path is sufficiently long (I believe it's just if it's longer than your system site-packages' absolute path), then running bin/buildout (vs. the system buildout) will decide NOT to include eggs/zc.buildout in the buildout_paths list in parts/buildout/site.py. The result of this is that the zc.buildout egg gets left out of pkg_resources.working_set, which means that when buildout tries to find itself in the working set, it fails, resulting in the following error: $ bin/buildout Upgraded: zc.buildout version 1.5.2; restarting. Traceback (most recent call last): File "bin/buildout", line 17, in <module> import zc.buildout.buildout File "/usr/lib/python2.6/site-packages/zc.buildout-1.5.2-py2.6.egg/zc/buildout/buildout.py", line 39, in <module> import zc.buildout.download File "/usr/lib/python2.6/site-packages/zc.buildout-1.5.2-py2.6.egg/zc/buildout/download.py", line 20, in <module> from zc.buildout.easy_install import realpath File "/usr/lib/python2.6/site-packages/zc.buildout-1.5.2-py2.6.egg/zc/buildout/easy_install.py", line 81, in <module> pkg_resources.Requirement.parse('zc.buildout')).location AttributeError: 'NoneType' object has no attribute 'location' Notice that the buildout is using the site-packages zc.buildout egg, instead of the one in the local eggs directory. Steps to reproduce: $ cd really/really/long/directory/name/with/lots/of/stuff/emptydir $ buildout init $ bin/buildout Workaround: use "include-site-packages = false" in the [buildout] section. This strongly suggests to me that some part of the site-packages isolation mechanism is broken, at least for zc.buildout itself. It is successfully allowing zc.buildout to be imported from site-packages, but not letting setuptools see that it is present in site-packages. If it does this for other packages that refer to themselves in the way zc.buildout.easy_install does, they will similarly break. (Likewise anything expecting to find entry points, etc.) On a somewhat unrelated note, I am as of yesterday a new zc.buildout user... and I already have a buildout that compiles Erlang, Spidermonkey, CouchDB, and RabbitMQ, and sets them all up with a Celery daemon under Supervisord, all in about 63 lines of .ini file. To say that I am impressed with buildout is an extreme understatement. ;-)