Skip to content
Buildout is a deployment automation tool written in and extended with Python
Python Makefile
Branch: master
Clone or download
Fetching latest commit…
Cannot retrieve the latest commit at this time.
Type Name Latest commit message Commit time
Failed to load latest commit information.
bootstrap Fixed bootstrap help text: --buildout-version. Aug 6, 2015
doc Update reference.rst Jan 28, 2019
old-tutorial Initial bones Feb 11, 2017
src/zc Fix DeprecationWarning about MutableMapping. Aug 21, 2019
zc.recipe.egg_ Update Trove classifiers and URL Feb 21, 2019
.travis.yml Support coverage for subprocess. (#399) Jun 20, 2017
DEVELOPERS.txt This removes python 2.6 and 3.2 support. Jul 12, 2016
LICENSE.txt explicitly pruning doc and tutorial from egg Mar 30, 2017
buildout.cfg Remove unnecessary egg from buildout Aug 15, 2017
setup.cfg Tell travis not to test the 'preparing release' commits Oct 2, 2015 Back to development: 2.13.3 Jul 3, 2019



Travis CI build report

Buildout is a project designed to solve 2 problems:

  1. Application-centric assembly and deployment

    Assembly runs the gamut from stitching together libraries to create a running program, to production deployment configuration of applications, and associated systems and tools (e.g. run-control scripts, cron jobs, logs, service registration, etc.).

    Buildout might be confused with build tools like make or ant, but it is a little higher level and might invoke systems like make or ant to get its work done.

    Buildout might be confused with systems like puppet or chef, but it is more application focused. Systems like puppet or chef might use buildout to get their work done.

    Buildout is also somewhat Python-centric, even though it can be used to assemble and deploy non-python applications. It has some special features for assembling Python programs. It's scripted with Python, unlike, say puppet or chef, which are scripted with Ruby.

  2. Repeatable assembly of programs from Python software distributions

    Buildout puts great effort toward making program assembly a highly repeatable process, whether in a very open-ended development mode, where dependency versions aren't locked down, or in a deployment environment where dependency versions are fully specified. You should be able to check buildout into a VCS and later check it out. Two checkouts built at the same time in the same environment should always give the same result, regardless of their history. Among other things, after a buildout, all dependencies should be at the most recent version consistent with any version specifications expressed in the buildout.

    Buildout supports applications consisting of multiple programs, with different programs in an application free to use different versions of Python distributions. This is in contrast with a Python installation (real or virtual), where, for any given distribution, there can only be one installed.

To learn more about buildout, including how to use it, see

You can’t perform that action at this time.