Skip to content
This repository

Merge pull request #180 from NextThought/master

Close various files when finished writing to them; fixes ResourceWarnings and some PyPy uses.
latest commit 8df1e8dbc5
Marius Gedminas mgedmin authored
Octocat-spinner-32 bootstrap adding allow-site-packages to allow for site package imports July 20, 2013
Octocat-spinner-32 doc old-style distutils scripts are now also detected in zipped eggs September 04, 2009
Octocat-spinner-32 specifications Fixed several tiny typos. March 24, 2013
Octocat-spinner-32 src Unify three checks for a file being changed into one function. Note t… April 07, 2014
Octocat-spinner-32 zc.recipe.egg_ List all Python versions supported February 28, 2014
Octocat-spinner-32 .gitignore ignore dist too December 04, 2012
Octocat-spinner-32 .travis.yml Removed exclusion of everything except the master branch. January 25, 2013
Octocat-spinner-32 2.4.cfg Python 2.4 and 2.5 compat September 03, 2012
Octocat-spinner-32 CHANGES.rst Close various files when finished writing to them. This avoids Resour… April 07, 2014
Octocat-spinner-32 COPYRIGHT.txt Conform to repository policy. February 28, 2011
Octocat-spinner-32 DEVELOPERS.txt Clarify Makefile instructions, remove me from explicit travis sender … August 25, 2012
Octocat-spinner-32 LICENSE.txt Conform to repository policy. February 28, 2011
Octocat-spinner-32 MANIFEST.in Adding missing *.test files to manifest, needed for manuel tests January 28, 2013
Octocat-spinner-32 Makefile Make Python tarball download URL https March 21, 2014
Octocat-spinner-32 README.rst Fix English speling in README.rst July 30, 2013
Octocat-spinner-32 buildout.cfg Test passing on windows and Python 2.6 October 06, 2012
Octocat-spinner-32 dev.py Update to new (provisional?) ez_setup.py URL. June 09, 2013
Octocat-spinner-32 setup.py svb September 05, 2013
Octocat-spinner-32 test_all_pythons.cfg added config for building test runners for all relevant Python versions July 22, 2009
README.rst

Buildout

Travis CI build report winbot 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 http://buildout.org/.

Installation

There are a number of ways to install buildout. You can install it as you would any other package, using pip or easy_install. In this case, you'll get a buildout command that you can use to build projects. To build a project, just use:

buildout

from a project directory.

Buildout's (stubborn) philosophy, however, is that projects should be self-contained, and not require changes to a shared Python installation. To avoid changing a shared Python installation you can download a bootstrap script that, when run, will install buildout locally in your project.

The bootstrap script for buildout version 2 is at:

http://downloads.buildout.org/2/bootstrap.py

So, for example, to install buildout 2 in a project, you might:

wget http://downloads.buildout.org/2/bootstrap.py
python bootstrap.py

Then to build your project, you can just run:

bin/buildout

from the project directory.

The bootstrap script is often checked into version control.

buildout 2 is somewhat backward-incompatible with version 1. Most projects will probably work fine with either. If you need to keep using version 1, however, specify a version requirement when you use pip or easy_install, or use the version 1 bootstrap script at:

http://downloads.buildout.org/1/bootstrap.py
Something went wrong with that request. Please try again.