Commit 7d39f450 authored by Jim Fulton's avatar Jim Fulton

Change the bootstrap method to not run the bootstrap.

Fixed a bunch of typos in tests
parent e8f84238
...@@ -165,8 +165,7 @@ class Buildout(dict): ...@@ -165,8 +165,7 @@ class Buildout(dict):
return os.path.join(self._buildout_dir, *names) return os.path.join(self._buildout_dir, *names)
def bootstrap(self, args): def bootstrap(self, args):
# Set up the actual buildout self._setup_directories()
self.install(args)
# Now copy buildout and setuptools eggs, amd record destination eggs: # Now copy buildout and setuptools eggs, amd record destination eggs:
entries = [] entries = []
...@@ -195,15 +194,8 @@ class Buildout(dict): ...@@ -195,15 +194,8 @@ class Buildout(dict):
['zc.buildout'], ws, sys.executable, ['zc.buildout'], ws, sys.executable,
self['buildout']['bin-directory']) self['buildout']['bin-directory'])
def install(self, install_parts): def install(self, install_parts):
self._setup_directories()
# Create buildout directories
for name in ('bin', 'parts', 'eggs', 'develop-eggs'):
d = self['buildout'][name+'-directory']
if not os.path.exists(d):
self._logger.info('Creating directory %s', d)
os.mkdir(d)
# Add develop-eggs directory to path so that it gets searched # Add develop-eggs directory to path so that it gets searched
# for eggs: # for eggs:
...@@ -279,6 +271,15 @@ class Buildout(dict): ...@@ -279,6 +271,15 @@ class Buildout(dict):
) )
self._save_installed_options(installed_part_options) self._save_installed_options(installed_part_options)
def _setup_directories(self):
# Create buildout directories
for name in ('bin', 'parts', 'eggs', 'develop-eggs'):
d = self['buildout'][name+'-directory']
if not os.path.exists(d):
self._logger.info('Creating directory %s', d)
os.mkdir(d)
def _develop(self): def _develop(self):
"""Install sources by running setup.py develop on them """Install sources by running setup.py develop on them
""" """
......
...@@ -11,7 +11,7 @@ may refer to such an instance of the application informally as "a Foo ...@@ -11,7 +11,7 @@ may refer to such an instance of the application informally as "a Foo
buildout". buildout".
This document describes how to define buildouts using buildout This document describes how to define buildouts using buildout
configuation files and recipes. There are two ways to set up the configuration files and recipes. There are two ways to set up the
buildout software and create a buildout instance: buildout software and create a buildout instance:
1. Install the zc.buildout egg with easy_install and use the buildout 1. Install the zc.buildout egg with easy_install and use the buildout
...@@ -33,8 +33,8 @@ parts defined. ...@@ -33,8 +33,8 @@ parts defined.
We have a sample buildout that has already been created for us. It We have a sample buildout that has already been created for us. It
has the absolute minimum information. We have bin, develop-eggs, eggs has the absolute minimum information. We have bin, develop-eggs, eggs
and parts directories, a configuration file, and an .installed,cfg and parts directories, a configuration file, and an .installed.cfg
that contains informatiion about previously-installed parts: that contains information about previously-installed parts:
>>> ls(sample_buildout) >>> ls(sample_buildout)
- .installed.cfg - .installed.cfg
...@@ -61,7 +61,7 @@ The develop-eggs and parts directories are initially empty: ...@@ -61,7 +61,7 @@ The develop-eggs and parts directories are initially empty:
The develop-eggs directory holds egg links for software being The develop-eggs directory holds egg links for software being
developed in the buildout. We separate develop-eggs and other eggs to developed in the buildout. We separate develop-eggs and other eggs to
allow eggs directories to be shared accross multiple buildouts. For allow eggs directories to be shared across multiple buildouts. For
example, a common developer technique is to define a common eggs example, a common developer technique is to define a common eggs
directory in their home that all non-develop eggs are stored in. This directory in their home that all non-develop eggs are stored in. This
allows larger buildouts to be set up much more quickly and saves disk allows larger buildouts to be set up much more quickly and saves disk
...@@ -70,12 +70,12 @@ space. ...@@ -70,12 +70,12 @@ space.
The parts directory provides an area where recipes can install The parts directory provides an area where recipes can install
part data. For example, if we built a custom Python, we would part data. For example, if we built a custom Python, we would
install it in the part directory. Part data is stored in a install it in the part directory. Part data is stored in a
subdirectory of the parts directory with the same name as the part. sub-directory of the parts directory with the same name as the part.
Buildouts are defined using configuration files. These are in the Buildouts are defined using configuration files. These are in the
format defined by the Python ConfigParser module, with extensions format defined by the Python ConfigParser module, with extensions
that we'll describe later. By default, when a buildout is run, it that we'll describe later. By default, when a buildout is run, it
looks for the file buildout.cfg in the directory where the buidout is looks for the file buildout.cfg in the directory where the buildout is
run. run.
The minimal configuration file has a buildout section that defines no The minimal configuration file has a buildout section that defines no
...@@ -95,7 +95,7 @@ interesting: ...@@ -95,7 +95,7 @@ interesting:
A part is simply something to be created by a buildout. It can be A part is simply something to be created by a buildout. It can be
almost anything, such as a Python package, a program, a directory, or almost anything, such as a Python package, a program, a directory, or
even a confguration file. even a configuration file.
A part is created by a recipe. Recipes are always installed as Python A part is created by a recipe. Recipes are always installed as Python
eggs. They can be downloaded from a package server, such as the eggs. They can be downloaded from a package server, such as the
...@@ -154,7 +154,7 @@ changed, or if the recipe has changed, then the part is uninstalled ...@@ -154,7 +154,7 @@ changed, or if the recipe has changed, then the part is uninstalled
before reinstalling it. The buildout only looks at the part's before reinstalling it. The buildout only looks at the part's
options, so any data used to configure the part needs to be reflected options, so any data used to configure the part needs to be reflected
in the part's options. It is the job of a recipe constructor to make in the part's options. It is the job of a recipe constructor to make
sure that the options include all relevent data. sure that the options include all rel event data.
Of course, parts are also uninstalled if they are no-longer used. Of course, parts are also uninstalled if they are no-longer used.
...@@ -164,7 +164,7 @@ path option from our options dictionary. ...@@ -164,7 +164,7 @@ path option from our options dictionary.
The install method logs what it's doing using the Python logging call. The install method logs what it's doing using the Python logging call.
We return the path that we installed. If the part is unistalled or We return the path that we installed. If the part is uninstalled or
reinstalled, then the path returned will be removed by the buildout reinstalled, then the path returned will be removed by the buildout
machinery. A recipe install method is expected to return None, a machinery. A recipe install method is expected to return None, a
string, or an iterable of strings containing paths to be removed if a string, or an iterable of strings containing paths to be removed if a
...@@ -408,7 +408,7 @@ Valid names are options in the same section and options defined in the ...@@ -408,7 +408,7 @@ Valid names are options in the same section and options defined in the
DEFAULT section. DEFAULT section.
We used a string-template substitution for file1. This type of We used a string-template substitution for file1. This type of
substituion uses the string.Template syntax. Names substited are substitution uses the string.Template syntax. Names substituted are
qualified option names, consisting of a section name and option name qualified option names, consisting of a section name and option name
joined by a colon. joined by a colon.
...@@ -445,7 +445,7 @@ the buildout: ...@@ -445,7 +445,7 @@ the buildout:
We can see that mydata was not recreated. We can see that mydata was not recreated.
Note that, in this vase, we didn't specify a log level, so Note that, in this case, we didn't specify a log level, so
we didn't get output about what the buildout was doing. we didn't get output about what the buildout was doing.
Multiple configuration files Multiple configuration files
...@@ -475,7 +475,7 @@ To see how this works, we use an example: ...@@ -475,7 +475,7 @@ To see how this works, we use an example:
... extends = base.cfg ... extends = base.cfg
... ...
... [debug] ... [debug]
... op = buldout ... op = buildout
... """) ... """)
>>> write(sample_buildout, 'base.cfg', >>> write(sample_buildout, 'base.cfg',
...@@ -490,7 +490,7 @@ To see how this works, we use an example: ...@@ -490,7 +490,7 @@ To see how this works, we use an example:
... """) ... """)
>>> print system(buildout), >>> print system(buildout),
op buldout op buildout
recipe recipes:debug recipe recipes:debug
The example is pretty trivial, but the pattern it illustrates is The example is pretty trivial, but the pattern it illustrates is
...@@ -622,7 +622,7 @@ User defaults ...@@ -622,7 +622,7 @@ User defaults
If the file $HOME/.buildout/defaults.cfg, exists, it is read before If the file $HOME/.buildout/defaults.cfg, exists, it is read before
reading the configuration file. ($HOME is the value of the HOME reading the configuration file. ($HOME is the value of the HOME
enviornment variable. The '/' is replaced by the operating system file environment variable. The '/' is replaced by the operating system file
delimiter.) delimiter.)
>>> home = mkdtemp() >>> home = mkdtemp()
...@@ -658,9 +658,9 @@ command usage is:: ...@@ -658,9 +658,9 @@ command usage is::
buildout [-c file] [-q] [-v] [assignments] [command [command arguments]] buildout [-c file] [-q] [-v] [assignments] [command [command arguments]]
The -c option can be used to specify a configuration file, rather than The -c option can be used to specify a configuration file, rather than
buildout.cfg in the current durectory. buildout.cfg in the current directory.
The -q and -v decrement and incremement the verbosity by 10. The The -q and -v decrement and increment the verbosity by 10. The
verbosity is used to adjust the logging level. The verbosity is verbosity is used to adjust the logging level. The verbosity is
subtracted from the numeric value of the log-level option specified in subtracted from the numeric value of the log-level option specified in
the configuration file. the configuration file.
...@@ -823,7 +823,7 @@ Now we'll update our configuration file: ...@@ -823,7 +823,7 @@ Now we'll update our configuration file:
... x = 1 ... x = 1
... """) ... """)
and run the buildout specifying just d2 and d3: and run the buildout specifying just d3 and d4:
>>> print system(buildout+' -v install d3 d4'), >>> print system(buildout+' -v install d3 d4'),
buildout: Running /sample-buildout/recipes/setup.py -q develop ... buildout: Running /sample-buildout/recipes/setup.py -q develop ...
...@@ -850,7 +850,7 @@ and run the buildout specifying just d2 and d3: ...@@ -850,7 +850,7 @@ and run the buildout specifying just d2 and d3:
d parts d parts
d recipes d recipes
Only the d2 and d3 recipes ran. d2 was removed and data2 and data3 Only the d3 and d4 recipes ran. d3 was removed and data3 and data4
were created. were created.
The .installed.cfg is only updated for the recipes that ran: The .installed.cfg is only updated for the recipes that ran:
...@@ -1032,11 +1032,11 @@ of changing the format: ...@@ -1032,11 +1032,11 @@ of changing the format:
Here, we've changed the format to include the log-level name, rather Here, we've changed the format to include the log-level name, rather
than the logger name. Note that we had to double percent signs, than the logger name. Note that we had to double percent signs,
because configuration options allow ConfigParser variable substituion. because configuration options allow ConfigParser variable substitution.
We've also illustrated, with a contrived example, that the log level We've also illustrated, with a contrived example, that the log level
can be a numeric value and that the verbosity can be specified in the can be a numeric value and that the verbosity can be specified in the
configuration file. Because the verbosoty is subtracted from the log configuration file. Because the verbosity is subtracted from the log
level, we get a final log level of 20, which is the INFO level. level, we get a final log level of 20, which is the INFO level.
>>> print system(buildout), >>> print system(buildout),
...@@ -1045,7 +1045,7 @@ level, we get a final log level of 20, which is the INFO level. ...@@ -1045,7 +1045,7 @@ level, we get a final log level of 20, which is the INFO level.
Predefined buildout options Predefined buildout options
--------------------------- ---------------------------
Buildouts have a number of pre-defined options that recipes can use Buildouts have a number of predefined options that recipes can use
and that users can override in their configuration files. To see and that users can override in their configuration files. To see
these, we'll run a minimal buildout configuration with a debug logging these, we'll run a minimal buildout configuration with a debug logging
level. One of the features of debug logging is that the configuration level. One of the features of debug logging is that the configuration
...@@ -1085,7 +1085,7 @@ bin-directory ...@@ -1085,7 +1085,7 @@ bin-directory
develop-eggs-directory develop-eggs-directory
The directory path where development egg links are created for software The directory path where development egg links are created for software
being craeted in the local project. This can be a relative path, being created in the local project. This can be a relative path,
which is interpreted relative to the directory option. which is interpreted relative to the directory option.
directory directory
...@@ -1094,7 +1094,7 @@ directory ...@@ -1094,7 +1094,7 @@ directory
eggs-directory eggs-directory
The directory path where downloaded eggs are put. It is common to share The directory path where downloaded eggs are put. It is common to share
this directory accross buildouts. Eggs in this directory should this directory across buildouts. Eggs in this directory should
*never* be modified. This can be a relative path, which is *never* be modified. This can be a relative path, which is
interpreted relative to the directory option. interpreted relative to the directory option.
...@@ -1116,14 +1116,14 @@ log-level ...@@ -1116,14 +1116,14 @@ log-level
The log level before verbosity adjustment The log level before verbosity adjustment
parts parts
A whitespace list of parts to be installed. A white space separated list of parts to be installed.
parts-directory parts-directory
A working directory that parts can used to store data. A working directory that parts can used to store data.
python python
The name of a section containing information about the default The name of a section containing information about the default
Python interpreter. Recipies that need a installation Python interpreter. Recipes that need a installation
typically have options to tell them which Python installation to typically have options to tell them which Python installation to
use. By convention, if a section-specific option isn't used, the use. By convention, if a section-specific option isn't used, the
option is looked for in the buildout section. The option must option is looked for in the buildout section. The option must
...@@ -1147,7 +1147,7 @@ local buildout scripts. There must be an existing setup.cfg: ...@@ -1147,7 +1147,7 @@ local buildout scripts. There must be an existing setup.cfg:
>>> write(sample_bootstrapped, 'setup.cfg', >>> write(sample_bootstrapped, 'setup.cfg',
... ''' ... '''
... [buildout] ... [buildout]
... parts = ... parts = foo this will not be read :)
... ''') ... ''')
>>> print system(buildout >>> print system(buildout
...@@ -1155,7 +1155,6 @@ local buildout scripts. There must be an existing setup.cfg: ...@@ -1155,7 +1155,6 @@ local buildout scripts. There must be an existing setup.cfg:
... +' bootstrap'), ... +' bootstrap'),
>>> ls(sample_bootstrapped) >>> ls(sample_bootstrapped)
- .installed.cfg
d bin d bin
d develop-eggs d develop-eggs
d eggs d eggs
...@@ -1172,5 +1171,9 @@ local buildout scripts. There must be an existing setup.cfg: ...@@ -1172,5 +1171,9 @@ local buildout scripts. There must be an existing setup.cfg:
>>> ls(sample_bootstrapped, 'develop-eggs') >>> ls(sample_bootstrapped, 'develop-eggs')
- zc.buildout.egg-link - zc.buildout.egg-link
Note that, in this example, we were using a development egg for the Note that, in this example, we were using a development egg for the
buildout, and the ac.buildout egg ended up as an egg link. buildout, and the ac.buildout egg ended up as an egg link.
Also not that the buildout script was installed but not run. To run
the buildout, we'd have to run the installed buildout script.
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