Directory Structure of a Buildout

A script to be included with each project to help a new developer set up the tree for use with zc.buildout after checking out the project. It installs from the network the zc.buildout and setuptools packages into the project directory.

The actual URL for fetching the file is:


Contains the default build specification for the entire project but others can be defined such as deployment.cfg and production.cfg. Specification files can include other specification files.


A hidden file that represents the current build state of the project. The zc.buildout software updates it as parts are installed or removed. The file is used by zc.buildout to compute the minimum set of changes to bring the project into sync with the buildout.cfg or other specification file.


Each part may create a holding directory underneath parts/ for the specific use of the part’s recipe. The part directory belongs to the recipe responsible for installing/uninstalling the part and is not intended for modification by the developer.


The directory holds a kind of symlink or shortcut link to the development directories elsewhere on the system of distributions being worked on. The content of the directory is manipulated by zc.buildout in response to “develop = DIRS” entries in the build specification file.


The directory receives executable scripts that zc.buildout creates from entrypoints defined within eggs and called out in the build specification.


The command to invoked zc.buildout for bringing the state of the project directory into sync with a particular build specification.


Just an example of a specific instance of a Python interpreter that encompasses a specific set of parts. The name is arbitrary and there can be any number of such custom interpreters.


A cache directory of eggs pulled down from the net, ready for mapping onto the sys.path of specific parts, as given in the build specification. This directory may be shared across projects if configured to be in a common nnlocation, increasing the speed with which buildouts can be constructed.


A cache directory of raw files pulled down from the net, such as compressed eggs, zipfiles, etc. After being downloaded into this directory, the contents are usually unpacked under a part name under the parts/. This directory may also be shared across projects, for greater efficiency.


Not strictly part of zc.buildout this directory appears when running within a sandbox created by virtualenv. It represents a standard Python lib/ hierarchy underwhich anything installed is outside the control of zc.buildout. It generally should be left alone.


Not strictly part of zc.buildout either, it is a scratch directory used by distutils/setuptools in the process of constructing eggs.


Not strictly part of zc.buildout, this directory receives the final packed representations of distributions such as eggs ready for uploading or sharing.

Here’s a list of files and directories that you can ignore in your version control system software:


Now you are familiar with installation and directory structure of a typical buildout project. Next step is to learn using buildout to develop a package .