Directory Structure of a Buildout¶
bootstrap.py
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 bootstrap.py file is:
buildout.cfg
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.
.installed.cfg
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.
parts/
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.
develop-eggs/
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.
bin/
The directory receives executable scripts that zc.buildout creates from entrypoints defined within eggs and called out in the build specification.
bin/buildout
The command to invoked zc.buildout for bringing the state of the project directory into sync with a particular build specification.
bin/mypython
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.
eggs/
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.
downloads/
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.
lib/
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.
build/
Not strictly part of zc.buildout either, it is a scratch directory used by distutils/setuptools in the process of constructing eggs.
dist/
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:
.installed.cfg
parts
develop-eggs
bin
eggs
downloads
lib
build
dist
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 .