Commit 7397d0be authored by jim's avatar jim

Reverted to last known good state. The factoring was too hard. :)

It would have broken old bootstrap scripts.  Now my problem is that if
I update buildout in a way that recipes depend on, people will have to
update their buildouts by running the bootstrap script. This isn't ideal.


git-svn-id: http://svn.zope.org/repos/main/zc.buildout/trunk@69879 62d5b8a3-27da-0310-9561-8e5933582275
parent 327253ee
[buildout] [buildout]
develop = zc.recipe.egg_ zc.recipe.testrunner zc.buildoutsupport develop = zc.recipe.egg_ zc.recipe.testrunner
parts = test parts = test
# prevent slow access to cheeseshop: # prevent slow access to cheeseshop:
......
- Need a better way to handle buildout updates. If I update buildout
and new versions of recipes depend on that, people will have to use
the bootstrap script to get a newer version of buildout or the
recipes won't load correctly.
I either need a more clever recipe loader that can load older
recipes when newer recipes aren't compatible with the existing
buildout version, or I need to make the buildout self updating.
- Use setuptools PackageIndex objects to improve performance by - Use setuptools PackageIndex objects to improve performance by
deciding whether we need to download anything without using deciding whether we need to download anything without using
easy_install. easy_install.
......
=============
Zope Buildout
=============
.. contents::
The Zope Buildout project provides support for creating applications,
especially Python applications. It provides tools for assembling
applications from multiple parts, Python or otherwise. An application
may actually contain multiple programs, processes, and configuration
settings.
Here's an example of such an application that we built with an earlier
prototype of the buildout system. We have a Zope application consisting of:
- Multiple Zope instances
- 4 ZEO servers
- An LDAP server
- Cache-invalidation and Mail delivery servers
- Dozens of add-on packages
- Multiple test runners
- Multiple deployment modes, including dev, stage, and prod,
with prod deployment over multiple servers
Parts installed include:
- Application software installs, including Zope, ZEO and LDAP
software
- Add-on packages
- Bundles of configuration that define Zope, ZEO and LDAP instances
- Utility scripts such as test runners, server-control
scripts, cron jobs.
This is all defined using configuration files and recipes, which are
software that build and installs parts based on configuration data.
The prototype system has minimal documentation and no tests and
has no egg support. (It build on earlier make-based systems that had
no documentation or tests.)
This project provides a non-prototype implementation of the ideas and
knowledge gained from earlier efforts and leverages setuptools to make
recipe management cleaner and to provide better Python package and
script management.
The word "buildout" refers to a description of a set of parts and the
software to create and assemble them. It is often used informally to
refer to an installed system based on a buildout definition. For
example, if we are creating an application named "Foo", then "the Foo
buildout" is the collection of configuration and application-specific
software that allows an instance of the application to be created. We
may refer to such an instance of the application informally as "a Foo
buildout".
I expect that, for many Zope packages, we'll arrange the package
projects in subversion as buildouts. To work on the package, someone
will check the project out of Subversion and build it. Building it
will assemble all of packages and programs needed to work on it. For
example, a buildout for a project to provide a new security policy
will include the source of the policy and specifications to build the
application for working on it, including:
- a test runner
- a web server for running the user interface
- supporting packages
A buildout will typically contain a copy of bootstrap.py. When
someone checks out the project, they'll run bootstrap.py, which will
- create support directories, like bin, eggs, and work, as needed,
- download and install the zc.buildout and setuptools eggs,
- run bin/build (created by installing zc.buildout) to build the
application.
Buildouts are defined using configuration files. These files are
based on the Python ConfigParser module with some variable-definition
and substitution extensions.
Installation
============
There are two ways to install zc,buildout
1. Install it as an egg using `easy_install
<http://peak.telecommunity.com/DevCenter/EasyInstall>`_ into a
Python instaallation. Then just use the buildout script from your
Python bin or Scripts directory.
2. Use the `bootstrap script
<http://dev.zope.org/Buildout/bootstrap.py>`_ to install setuptools
and the buildout software into your buildout. Typically, you'll
check the bootstrap script into your project so that, whenever you
checkout your project, you can turn it into a buildout by just
running the bootstrap script.
More information
================
The detailed documentation for the various parts of buildout can be
found in the following files:
`buildout.txt <http://dev.zope.org/Buildout/buildout.html>`_
Describes how to define and run buildouts. It also describes how
to write recipes.
`easy_install.txt <http://dev.zope.org/Buildout/easy_install.html>`_
Describes an Python APIs for invoking easy_install for generation
of scripts with paths baked into them.
Download
========
You can download zc.buildout and many buildout recipes from the
`Python Package Index <http://www.python.org/pypi>`_.
Recipes
=======
Existing recipes include:
`zc.recipe.egg <http://dev.zope.org/Buildout/egg.html>`_
The egg recipe installes one or more eggs, with their
dependencies. It installs their console-script entry points with
the needed eggs included in their paths.
`zc.recipe.testrunner <http://dev.zope.org/Buildout/testrunner.html>`_
The testrunner egg installs creates a test runner script for one or
more eggs.
`zc.recipe.zope3checkout <http://dev.zope.org/Buildout/zope3checkout.html>`_
The zope3checkout recipe installs a Zope 3 checkout into a
buildout.
`zc.recipe.zope3instance <http://dev.zope.org/Buildout/zope3instance.html>`_
The zope3instance recipe sets up a Zope 3 instance.
`zc.recipe.filestorage <http://dev.zope.org/Buildout/filestorage.html>`_
The filestorage recipe sets up a ZODB file storage for use in a
Zope 3 instance creayed by the zope3instance recipe.
Buildout examples
=================
Some simple buildout examples:
`The zc.buildout project <http://svn.zope.org/zc.buildout/trunk>`_
This is the project for the buildout software itself, which is
developed as a buildout.
`The zc sharing project <http://svn.zope.org/zc.sharing/trunk>`_
This project illistrates using the buildout software with Zope 3.
Note that the bootstrap.py file is checked in so that a buildout
can be made when the project is checked out. The buildout.cfg
specified everything needed to create a Zope 3 installation with
the zc.sharing package installed in development mode.
Status
======
The buildout system is under active development. Some near term
priorities include:
- Better error reporing
- Windows support
- Handling of egg extras
- More recipes
Questions
=========
You can send questions to jim@zope.com.
Change History
==============
1.0.0b3
-------
- Added Windows support.
- Fixed some bugs in variable substitutions.
The characters "-", "." and " ", weren't allowed in section or
option names.
Substitutions with invalid names were ignored, which caused
missleading failures downstream.
- Improved error handling. No longer show tracebacks for user errors.
- Now require a recipe option (and therefore a section) for every part.
1.0.0b2
-------
Added support for specifying some build_ext options when installing eggs
from source distributions.
1.0.0b1
-------
- Changed the bootstrapping code to only install setuptools and
zc.buildout. The bootstrap code no-longer runs the buildout itself.
This was to fix a bug that caused parts to be recreated
unnecessarily because the recipe signature in the initial buildout
reflected temporary locations for setuptools and zc.buildout.
- Now create a minimal setup.py if it doesn't exist and issue a
warning that it is being created.
- Fixed bug in saving installed configuration data. %'s and extra
spaces weren't quoted.
1.0.0a1
-------
Initial public version
from setuptools import setup, find_packages
name = "zc.buildout"
setup(
name = name,
version = "1.0.0b2",
author = "Jim Fulton",
author_email = "jim@zope.com",
description = "System for managing development buildouts",
long_description=open('README.txt').read(),
license = "ZPL 2.1",
keywords = "development build",
url='http://svn.zope.org/zc.buildout',
data_files = [('.', ['README.txt'])],
packages = ['zc', 'zc.buildout'],
package_dir = {'': 'src'},
namespace_packages = ['zc'],
install_requires = 'setuptools',
include_package_data = True,
tests_require = ['zope.testing'],
test_suite = name+'.tests.test_suite',
entry_points = {'console_scripts':
['buildout = %s.buildout:main' % name]},
dependency_links = ['http://download.zope.org/distribution/'],
)
try:
__import__('pkg_resources').declare_namespace(__name__)
except:
# bootstrapping
pass
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
This diff is collapsed.
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment