System for managing development buildouts
Buildout is a project designed to solve 2 problems:
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.
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 http://docs.buildout.org/.
- Made upgrade check more robust. When using extensions, the improvement introduced in 2.11 could prevent buildout from restarting itself when it upgraded setuptools.
- Installed packages are added to the working set immediately. This helps in some corner cases that occur when system packages have versions that conflict with our specified versions.
Setuptools 38.2.0 started supporting wheels. Through setuptools, buildout now also supports wheels! You need at least version 38.2.3 to get proper namespace support.
This setuptools change interfered with buildout’s recent support for buildout.wheel, resulting in a sudden “Wheels are not supported” error message (see issue 435). Fixed by making setuptools the default, though you can still use the buildout.wheel if you want.
- Fixed: could not install eggs when sdist file name and package name had different case.
- Use HTTPS for PyPI’s index. PyPI redirects HTTP to HTTPS by default now so using HTTPS directly avoids the potential for that redirect being modified in flight.
Sort the distributions used to compute __buildout_signature__ to ensure reproducibility under Python 3 or under Python 2 when -R is used on PYTHONHASHSEED is set to random. Fixes issue 392.
NOTE: This may cause existing .installed.cfg to be considered outdated and lead to parts being reinstalled spuriously under Python 2.
Add support code for doctests to be able to easily measure code coverage. See issue 397.
- Add more verbosity to annotate results with -v
- Select one or more sections with arguments after buildout annotate.
- Fixed: We unnecessarily used a function from newer versions of setuptools that caused problems when older setuptools or pkg_resources installs were present (as in travis.ci).
- Fixed a minor packaging bug that broke the PyPI page.
- Added new syntax to explicitly declare that a part depends on other part. See http://docs.buildout.org/en/latest/topics/implicit-parts.html
- Internal refactoring to work with buildout.wheel.
- Fixed a bugs in zc.buildout.testing.Buildout. It was loading user-default configuration. It didn’t support calling the created method on its sections.
- Fixed a bug (windows, py 3.4) When processing metadata on “old-style” distutils scripts, .exe stubs appeared in metadata_listdir, in turn reading those burped with UnicodeDecodeError. Skipping .exe stubs now.
- Added a hook to enable a soon-to-be-released buildout extension to provide wheel support.
- Fixed a bug introduced in 2.6.0: zc.buildout and its dependeoncies were reported as picked even when their versions were fixed in a versions section. Worse, when the update-versions-file option was used, the versions section was updated needlessly on every run.
Added a buildout option, abi-tag-eggs that, when true, causes the ABI tag for the buildout environment to be added to the eggs directory name.
This is useful when switching Python implementations (e.g. CPython vs PyPI or debug builds vs regular builds), especially when environment differences aren’t reflected in egg names. It also has the side benefit of making eggs directories smaller, because eggs for different Python versions are in different directories.
- Updated to work with the latest setuptools.
- Added (verified) Python 3.6 support.
- After a dist is fetched and put into its final place, compile its python files. No longer wait with compiling until all dists are in place. This is related to the change below about not removing an existing egg. [maurits]
- Do not remove an existing egg. When installing an egg to a location that already exists, keep the current location (directory or file). This can only happen when the location at first did not exist and this changed during the buildout run. We used to remove the previous location, but this could cause problems when running two buildouts at the same time, when they try to install the same new egg. Fixes #307. [maurits]
- In zc.buildout.testing.system, set TERM=dumb in the environment. This avoids invisible control characters popping up in some terminals, like xterm. Note that this may affect tests by buildout recipes. [maurits]
- Removed Python 2.6 and 3.2 support. [do3cc]
- Fixed -= and += when extending sections. See #161. [puittenbroek]
- Fix python 2 for downloading external config files with basic auth in the URL. Fixes #257.
Added more elaborate version and requirement information when there’s a version conflict. Previously, you could get a report of a version conflict without information about which dependency requested the conflicing requirement.
Now all this information is logged and displayed in case of an error. [reinout]
Dropped 3.2 support (at least in the automatic tests) as setuptools will soon stop supporting it. Added python 3.5 to the automatic tests. [reinout]
- Fix for #279. Distutils script detection previously broke on windows with python 3 because it errored on .exe files. [reinout]
- Relative paths are now also correctly generated for the current directory (“develop = .”). [youngking]
- More complete fix for #24. Distutils scripts are now also generated for develop eggs. [reinout]
- zc.buildout is now also released as a wheel. (Note: buildout itself doesn’t support installing wheels yet.) [graingert]
- Added nested directory creation support [guyzmo]
- If a downloaded config file in the “extends-cache” gets corrupted, buildout now tells you the filename in the cache. Handy for troubleshooting. [reinout]
- Check the use-dependency-links option earlier. This can give a small speed increase. [maurits]
- When using python 2, urllib2 is used to work around Python issue 24599, which affects downloading from behind a proxy. [stefano-m]
- Buildout no longer breaks on packages that contain a file with a non-ascii filename. Fixes #89 and #148. [reinout]
- Undo breakage on Windows machines where sys.prefix can also be a site-packages directory: don’t remove it from sys.path. See https://github.com/buildout/buildout/issues/217 .
- Remove assumption that pkg_resources is a module (untrue since release of setuptools 8.3`). See https://github.com/buildout/buildout/issues/227 .
- Fix for #212. For certain kinds of conflict errors you’d get an UnpackError when rendering the error message. Instead of a nicely formatted version conflict message. [reinout]
- Making sure we use the correct easy_install when setuptools is installed globally. See https://github.com/buildout/buildout/pull/232 and https://github.com/buildout/buildout/pull/222 . [lrowe]
- Updated buildout’s travis-ci configuration so that tests run much quicker so that buildout is easier and quicker to develop. [reinout]
- Note: zc.recipe.egg has also been updated to 2.0.2 together with this zc.buildout release. Fixed: In zc.recipe.egg#custom recipe’s rpath support, don’t assume path elements are buildout-relative if they start with one of the “special” tokens (e.g., $ORIGIN). See: https://github.com/buildout/buildout/issues/225. [tseaver]
- download-cache, eggs-directory and extends-cache are now automatically created if their parent directory exists. Also they can be relative directories (relative to the location of the buildout config file that defines them). Also they can now be in the form ~/subdir, with the usual convention that the ~ char means the home directory of the user running buildout. [lelit]
- A new boostrap.py file is released (version 2015-07-01).
- When bootstrapping, the develop-eggs/ directory is first removed. This prevents old left-over .egg-link files from breaking buildout’s careful package collection mechanism. [reinout]
- The bootstrap script now accepts --to-dir. Setuptools is installed there. If already available there, it is reused. This can be used to bootstrap buildout without internet access. Similarly, a local ez_setup.py is used when available instead of it being downloaded. You need setuptools 14.0 or higher for this functionality. [lrowe]
- The bootstrap script now uses --buildout-version instead of --version to pick a specific buildout version. [reinout]
- The bootstrap script now accepts --version which prints the bootstrap version. This version is the date the bootstrap.py was last changed. A date is handier or less confusing than either tracking zc.buildout’s version or having a separate bootstrap version number. [reinout]
- Fixed: Buildout merged single-version requirements with version-range requirements in a way that caused it to think there wasn’t a single-version requirement. IOW, buildout throught that versions were being picked when they weren’t.
- Suppress spurios (and possibly non-spurious) version-parsing warnings.
- Buildout is now compatible with (and requires) setuptools 8.
- Improved fix for #198: when bootstrapping with an extension, buildout was too strict on itself, resulting in an inability to upgrade or downgrade its own version. [reinout]
- Setuptools must be at 3.3 or higher now. If you use the latest bootstrap from http://downloads.buildout.org/2/bootstrap.py you’re all set. [reinout]
- Installing recipes that themselves have dependencies used to fail with a VersionConflict if such a dependency was installed globally with a lower version. Buildout now ignores the version conflict in those cases and simply installs the correct version. [reinout]
- Fix for #198: buildout 2.2.3 caused a version conflict when bootstrapping a buildout with a version pinned to an earlier one. Same version conflict could occur with system-wide installed packages that were newer than the pinned version. [reinout]
- Fix #197, Python 3 regression [aclark4life]
- Open files for exec() in universal newlines mode. See https://github.com/buildout/buildout/issues/130
- Add BUILDOUT_HOME as an alternate way to control how the user default configuration is found.
- Close various files when finished writing to them. This avoids ResourceWarnings on Python 3, and better supports doctests under PyPy.
- Introduce improved easy_install Install.install function. This is present in 1.5.X and 1.7X but was never merged into 2.X somehow.
- distutils scripts: correct order of operations on from ... import lines (see https://github.com/buildout/buildout/issues/134).
- Add an --allow-site-packges option to bootstrap.py, defaulting to False. If the value is false, strip any “site packages” (as defined by the site module) from sys.path before attempting to import setuptools / pkg_resources.
- Updated the URL used to fetch ez_setup.py to the official, non-version- pinned version.
- Handle both addition and subtraction of elements (+= and -=) on the same key in the same section. Forward-ported from buildout 1.6.
- Suppress the useless Link to <URL> ***BLOCKED*** by --allow-hosts error message being emitted by distribute / setuptools.
- Extend distutils script generation to support module docstrings and __future__ imports.
- Refactored picked versions logic to make it easier to use for plugins.
- Use get_win_launcher API to find Windows launcher (falling back to resource_string for cli.exe).
- Remove data_files from setup.py: it was installing README.txt in current directory during installation (merged from 1.x branch).
- Switch dependency from distribute 0.6.x to setuptools 0.7.x.
- Meta-recipe support
- Conditional sections
- Buildout now accepts a --version command-line option to print its version.
- Fixed: Builout didn’t exit with a non-zero exit status if there was a
- failure in combination with an upgrade.
- Fixed: We now fail with an informative error when an old bootstrap
- script causes buildout 2 to be used with setuptools.
- Fixed: An error incorrectly suggested that buildout 2 implemented all
- of the functionality of dumppickedversions.
- Fixed: Buildout generated bad scripts when no eggs needed to be added
- to sys.path.
- Fixed: Buildout didn’t honour Unix umask when generating scripts.
- Fixed: update-versions-file didn’t work unless
- show-picked-versions was also set. https://github.com/buildout/buildout/issues/71
- Fixed: buildout didn’t honor umask settings when creating scripts.
- Fix for distutils scripts installation on Python 3, related to __pycache__ directories.
- Fixed: encoding data in non-entry-point-based scripts was lost.
Release history Release notifications | RSS feed
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
|Filename, size||File type||Python version||Upload date||Hashes|
|Filename, size zc.buildout-2.11.1-py2.py3-none-any.whl (155.4 kB)||File type Wheel||Python version py2.py3||Upload date||Hashes View|
|Filename, size zc.buildout-2.11.1.tar.gz (163.3 kB)||File type Source||Python version None||Upload date||Hashes View|
Hashes for zc.buildout-2.11.1-py2.py3-none-any.whl