Commit 75b2b450 authored by TomasM's avatar TomasM

pull from upstream

parents 7869eed9 284e2470
Change History
**************
2.1.0 (2013-??-??)
2.1.1dev (unreleased)
=====================
2.1.0 (2013-03-23)
==================
- Removed `data_files` from `setup.py`, which was installing README.rst
in current directory during installation
- `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.
https://bugs.launchpad.net/zc.buildout/+bug/180705
- Added `meta-recipe support`_.
Fixed: ``update-versions-file`` didn't work unless
``show-picked-versions`` was also set.
https://github.com/buildout/buildout/issues/71
2.0.1 (2013-02-16)
==================
......@@ -688,7 +712,7 @@ Feature Changes
this option.
- Adjusted the output for verbosity levels. Using a single -v option
no longer causes voluminous setuptools output. Uisng -vv and -vvv
no longer causes voluminous setuptools output. Using -vv and -vvv
now triggers extra setuptools output.
- Added a remove testing helper function that removes files or directories.
......@@ -707,7 +731,7 @@ Feature Changes
- Added a *newest* keyword parameter to the
zc.buildout.easy_install.install and zc.buildout.easy_install.build
functions to control whether the newest distributions that meed
functions to control whether the newest distributions that need
given requirements should be sought. If a false value is provided
for this parameter and already installed eggs meet the given
requirements, then no attempt will be made to search for newer
......
......@@ -12,7 +12,7 @@
#
##############################################################################
name = "zc.buildout"
version = "2.1.0dev"
version = "2.1.0"
import os
from setuptools import setup
......
......@@ -73,7 +73,7 @@ itself added an entry for the recipe that fixes the recipe version
at the version used by the buildout.
The zc.recipe.eggs recipe added the eggs option that lists the
specifoc releases that were assembled.
specific releases that were assembled.
Finally the buildout.cfg file can be modified to use the
repeatable.cfg file::
......@@ -88,7 +88,7 @@ repeatable.cfg file::
eek
When the buildout is run, the options in repeatable.cfg will override
the onces in buildout.cfg, providing a repeatable buildout
the ones in buildout.cfg, providing a repeatable buildout
Python API
----------
......
......@@ -37,7 +37,7 @@ Let's create a develop egg in our buildout that specifies
... ''')
Now let's configure the buildout to use the develop egg,
together with some rules that disallow any website but PyPI and
together with some rules that disallow any web site but PyPI and
local files::
>>> write(sample_buildout, 'buildout.cfg',
......
......@@ -146,13 +146,11 @@ _buildout_default_options = _annotate_section({
class Buildout(DictMixin):
def __init__(self, config_file, cloptions,
user_defaults=True, windows_restart=False,
user_defaults=True,
command=None, args=()):
__doing__ = 'Initializing.'
self.__windows_restart = windows_restart
# default options
data = dict(buildout=_buildout_default_options.copy())
self._buildout_dir = os.getcwd()
......@@ -347,7 +345,7 @@ class Buildout(DictMixin):
if self.offline:
raise zc.buildout.UserError(
"install-from-cache can't be used with offline mode.\n"
"Nothing is installed, even fromn cache, in offline\n"
"Nothing is installed, even from cache, in offline\n"
"mode, which might better be called 'no-install mode'.\n"
)
zc.buildout.easy_install.install_from_cache(True)
......@@ -451,7 +449,7 @@ class Buildout(DictMixin):
# for eggs:
sys.path.insert(0, self['buildout']['develop-eggs-directory'])
# Check for updates. This could cause the process to be rstarted
# Check for updates. This could cause the process to be restarted
self._maybe_upgrade()
# load installed data
......@@ -651,11 +649,11 @@ class Buildout(DictMixin):
f.close()
def _uninstall_part(self, part, installed_part_options):
# ununstall part
# uninstall part
__doing__ = 'Uninstalling %s.', part
self._logger.info(*__doing__)
# run uinstall recipe
# run uuinstall recipe
recipe, entry = _recipe(installed_part_options[part])
try:
uninstaller = _install_and_load(
......@@ -788,7 +786,7 @@ class Buildout(DictMixin):
==
realpath(f)
)
# Sigh. This is the exectable used to run the buildout
# Sigh. This is the executable used to run the buildout
# and, of course, it's in use. Leave it.
):
raise
......@@ -915,14 +913,6 @@ class Buildout(DictMixin):
"buildout command.")
return
if sys.platform == 'win32' and not self.__windows_restart:
args = list(map(zc.buildout.easy_install._safe_arg, sys.argv))
args.insert(1, '-W')
if not __debug__:
args.insert(0, '-O')
args.insert(0, zc.buildout.easy_install._safe_arg (sys.executable))
os.execv(sys.executable, args)
self._logger.info("Upgraded:\n %s;\nrestarting.",
",\n ".join([("%s version %s"
% (dist.project_name, dist.version)
......@@ -1475,7 +1465,7 @@ def _default_globals():
globals_defs = {'sys': sys, 'os': os, 'platform': platform, 're': re,}
# major python major_python_versions as python2 and python3
major_python_versions = platform.python_version_tuple()
major_python_versions = tuple(map(str, platform.python_version_tuple()))
globals_defs.update({'python2': major_python_versions[0] == '2',
'python3': major_python_versions[0] == '3'})
......@@ -1695,7 +1685,7 @@ def _error(*message):
sys.exit(1)
_internal_error_template = """
An internal error occured due to a bug in either zc.buildout or in a
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
"""
......@@ -1844,7 +1834,6 @@ def main(args=None):
config_file = 'buildout.cfg'
verbosity = 0
options = []
windows_restart = False
user_defaults = True
debug = False
while args:
......@@ -1856,8 +1845,6 @@ def main(args=None):
verbosity += 10
elif op[0] == 'q':
verbosity -= 10
elif op[0] == 'W':
windows_restart = True
elif op[0] == 'U':
user_defaults = False
elif op[0] == 'o':
......@@ -1912,7 +1899,7 @@ def main(args=None):
section, option = option
options.append((section.strip(), option.strip(), value.strip()))
else:
# We've run out of command-line options and option assignnemnts
# We've run out of command-line options and option assignments
# The rest should be commands, so we'll stop here
break
......@@ -1932,8 +1919,7 @@ def main(args=None):
try:
try:
buildout = Buildout(config_file, options,
user_defaults, windows_restart,
command, args)
user_defaults, command, args)
getattr(buildout, command)(args)
except SystemExit:
logging.shutdown()
......
......@@ -462,7 +462,7 @@ leave previously created paths in place:
While:
Installing data-dir.
<BLANKLINE>
An internal error occured due to a bug in either zc.buildout or in a
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
... exists...
......@@ -493,7 +493,7 @@ If we fix the typo:
While:
Installing data-dir.
<BLANKLINE>
An internal error occured due to a bug in either zc.buildout or in a
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
... exists...
......@@ -580,7 +580,7 @@ When we rerun the buildout:
While:
Installing data-dir.
<BLANKLINE>
An internal error occured due to a bug in either zc.buildout or in a
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
... exists...
......@@ -655,7 +655,7 @@ directories will be created:
While:
Installing data-dir.
<BLANKLINE>
An internal error occured due to a bug in either zc.buildout or in a
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
... exists...
......@@ -696,9 +696,12 @@ section has a section header followed by 0 or more section options.
files.)
A section header consists of a section name enclosed in square braces.
A section name consists of one or more non-whitespace characters
other than square braces ('[', ']'), curly braces ('{', '}'), colons
(':') or equal signs ('='). Whitespace surrounding section names is ignored.
A section name consists of one or more non-whitespace characters other
than square braces ('[', ']'), curly braces ('{', '}'), colons (':')
or equal signs ('='). Whitespace surrounding section names is ignored.
A section header can optionally have a condition expression separated
by a colon. See `Conditional sections`_.
Options consist of option names, followed by optional space or tab
characters, an optional plus or minus sign and an equal signs and
......@@ -714,7 +717,7 @@ Option values have extra whitespace stripped. How this is done
depends on whether the value has non-whitespace characterts on the
first line. If an option value has non-whitespace characters on the
first line, then each line is stripped and blank lines are removed.
For exampe, in::
For example, in::
[foo]
bar = 1
......@@ -765,7 +768,7 @@ Buildout configuration data are Python strings, which are bytes in
Python 2 and unicode in Python 3.
Sections and options within sections may be repeated. Multiple
occurrences of of a section are treated as if they were concantinated.
occurrences of of a section are treated as if they were concatenated.
The last option value for a given name in a section overrides previous
values.
......@@ -968,7 +971,7 @@ Section and option names in variable substitutions are only allowed to
contain alphanumeric characters, hyphens, periods and spaces. This
restriction might be relaxed in future releases.
We can ommit the section name in a variable substitution to refer to
We can omit the section name in a variable substitution to refer to
the current section. We can also use the special option,
_buildout_section_name_ to get the current section name.
......@@ -1131,6 +1134,133 @@ In this example, the debug, with_file1 and with_file2 sections act as
macros. In particular, the variable substitutions are performed
relative to the myfiles section.
Conditional sections
--------------------
Sometimes, you need different configuration in different environments
(different operating systems, or different versions of Python). To
make this easier, you can define environment-specific options by
providing conditional sections::
[ctl]
suffix =
[ctl:windows]
suffix = .bat
.. -> conf
>>> import zc.buildout.configparser
>>> zc.buildout.configparser.parse(
... StringIO.StringIO(conf), 'test', lambda : dict(windows=True))
{'ctl': {'suffix': '.bat'}}
>>> zc.buildout.configparser.parse(
... StringIO.StringIO(conf), 'test', lambda : dict(windows=False))
{'ctl': {'suffix': ''}}
In this tiny example, we've defined a ``ctl:suffix`` option that's
``.bat`` on Windows and an empty string elsewhere.
A conditional section has a colon and then a Python expression after
the name. If the Python expression result is true, the section
options from the section are included. If the value is false, the
section is ignored.
Some things to note:
- If there is no exception, then options from the section are
included.
- Sections and options can be repeated. If an option is repeated, the
last value is used. In the example above, on Windows, the second
``suffix`` option overrides the first. If the order of the sections
was reversed, the conditional section would have no effect.
In addition to the normal built-ins, the expression has access to
global variable that make common cases short and description as shown
above:
sys
the ``sys`` module
os
the ``os`` module
platform
the ``platform`` module
re
The ``re`` module
python2
We're running Python 2
python3
We're running Python 3
python26
We're running Python 2.6
python27
We're running Python 2.7
python32
We're running Python 3.2
python33
We're running Python 3.3
sys_version
``sys.version.lower()``
pypy
We're running PyPy
jython
We're running Jython
iron
We're running Iron Python
cpython
We're not running PyPy, Jython, or Iron Python
sys_platform
``str(sys.platform).lower()``
linux
We're running on linux
windows
We're running on Windows
cygwin
We're running on cygwin
solaris
We're running on solaris
macos
We're running on Mac OS
posix
We're running on a POSIX-compatible system
bits32
We're running on a 32-bit system.
bits64
We're running on a 64-bit system.
little_endian
We're running on a little-endian system
big_endian
We're running on a little-endian system
Expressions must not contain either the ``#`` or the ``;`` character.
Adding and removing options
---------------------------
......@@ -2703,12 +2833,12 @@ interpreter with the given requirements or paths:
extra-paths =
./src
Passing requirements or paths causes the the builout to be run as part
Passing requirements or paths causes the the buildout to be run as part
of initialization. In the example above, we got a number of
distributions installed and 2 scripts generated. The first, ``demo``,
was defined by the ``demo`` project. The second, ``py`` was defined by
the generated configuration. It's a "custom interpreter" that behaves
like a standard Python interpeter, except that includes the specified
like a standard Python interpreter, except that includes the specified
eggs and extra paths in it's Python path.
We specified a source directory that didn't exist. Buildout created it
......
......@@ -14,7 +14,7 @@
# The following copied from Python 2 config parser because:
# - The py3 configparser isn't backward compatible
# - Both strip option values in undesireable ways
# - Both strip option values in undesirable ways
# - dict of dicts is a much simpler api
import re
......@@ -82,7 +82,7 @@ class MissingSectionHeaderError(ParsingError):
# [section_name: some Python expression] #; some comment
# This regex leverages the fact that the following is a valid Python expression:
# [some Python expression] # some comment
# and that section headers are also delimited by [brackets] taht are also [list]
# and that section headers are also delimited by [brackets] that are also [list]
# delimiters.
# So instead of doing complex parsing to balance brackets in an expression, we
# capture just enough from a header line to collect then remove the section_name
......@@ -127,7 +127,7 @@ def parse(fp, fpname, exp_globals=dict):
Optionally the title line can have the form `[name:expression]' where
expression is an arbitrary Python expression. Sections with an expression
that evaluates to False are ignored. Semicolon `;' an hash `#' characters
mustr be string-escaped in expression literals.
must be string-escaped in expression literals.
exp_globals is a callable returning a mapping of defaults used as globals
during the evaluation of a section conditional expression.
......
......@@ -285,7 +285,7 @@ objects made available to the evaluation context of the expression. Here we add
the platform and sys modules to the evaluation context, so we can access
platform and sys modules functions and objects in our expressions ::
[s1: platform.python_version_tuple()[0] in ('2', '3',)] # this expression is true, the major versions of python are either 2 or 3
[s1: str(platform.python_version_tuple()[0]) in ('2', '3',)] # this expression is true, the major versions of python are either 2 or 3
a = 1
[s2:sys.version[0] == '0'] # comment: this expression "is false", there no major version 0 of Python so this section will be ignored
......
......@@ -5,7 +5,7 @@ Buildouts can be pretty complex. When things go wrong, it isn't
always obvious why. Errors can occur due to problems in user input or
due to bugs in zc.buildout or recipes. When an error occurs, Python's
post-mortem debugger can be used to inspect the state of the buildout
or recipe code were there error occured. To enable this, use the -D
or recipe code were there error occurred. To enable this, use the -D
option to the buildout. Let's create a recipe that has a bug:
>>> mkdir(sample_buildout, 'recipes')
......
......@@ -318,7 +318,7 @@ class Installer:
if exit_code:
logger.error(
"An error occured when trying to install %s. "
"An error occurred when trying to install %s. "
"Look above this message for any errors that "
"were output by easy_install.",
dist)
......@@ -1384,7 +1384,7 @@ def _constrained_requirement_constraint(constraint, requirement):
# Simple cases:
# No specs tp merge with:
# No specs to merge with:
if not requirement.specs:
if not constraint[0] in '<=>':
constraint = '==' + constraint
......@@ -1422,8 +1422,8 @@ def _constrained_requirement_constraint(constraint, requirement):
cop0 = cop[0]
# Normalize specs by splitting >= and <= specs. We meed tp do this
# becaise these have really weird semantics. Also cache parsed
# Normalize specs by splitting >= and <= specs. We need to do this
# because these have really weird semantics. Also cache parsed
# versions, which we'll need for comparisons:
specs = []
for op, v in requirement.specs:
......
......@@ -153,7 +153,7 @@ under any particular circumstances.
been specified by the user's default configuration, the project's root
config file must be available, be it from disk or from the net.
- Offline mode turned on by the ``-o`` command line option is honoured from
- Offline mode turned on by the ``-o`` command line option is honored from
the beginning even though command line options are applied to the
configuration last. If offline mode is not requested by the command line, it
may be switched on by either the user's or the project's config root.
......@@ -383,12 +383,12 @@ Error: Couldn't download 'http://localhost/base.cfg' in offline mode.
While:
Installing.
Checking for upgrades.
An internal error occured ...
An internal error occurred ...
ValueError: install_from_cache set to true with no download cache
>>> rmdir('home', '.buildout')
Newest and non-newest behaviour for extends cache
Newest and non-newest behavior for extends cache
-------------------------------------------------
While offline mode forbids network access completely, 'newest' mode determines
......@@ -467,7 +467,7 @@ used:
Unused options for buildout: 'bar' 'foo'.
(XXX We patch download utility's API to produce readable output for the test;
a better solution would utilise the logging already done by the utility.)
a better solution would re-use the logging already done by the utility.)
>>> import zc.buildout
>>> old_download = zc.buildout.download.Download.download
......@@ -489,7 +489,7 @@ Unused options for buildout: 'bar' 'foo'.
The deprecated ``extended-by`` option
-------------------------------------
The ``buildout`` section used to recognise an option named ``extended-by``
The ``buildout`` section used to recognize an option named ``extended-by``
that was deprecated at some point and removed in the 1.5 line. Since ignoring
this option silently was considered harmful as a matter of principle, a
UserError is raised if that option is encountered now:
......
......@@ -7,13 +7,13 @@ configuration files for a project into a version control system and
later use the checked in files to get the same buildout, subject to
changes in the environment outside the buildout.
An advantage of using Python eggs is that depenencies of eggs used are
An advantage of using Python eggs is that dependencies of eggs used are
automatically determined and used. The automatic inclusion of
depenent distributions is at odds with the goal of repeatable
dependent distributions is at odds with the goal of repeatable
buildouts.
To support repeatable buildouts, a versions section can be created
with options for each distribution name whos version is to be fixed.
with options for each distribution name who's version is to be fixed.
The section can then be specified via the buildout versions option.
To see how this works, we'll create two versions of a recipe egg:
......
......@@ -49,7 +49,7 @@ number of names to the test namespace:
will be automatically removed at the end of the test. The path of
the created directory is returned.
Further, if the the normalize_path normlaizing substitution (see
Further, if the the normalize_path normalizing substitution (see
below) is used, then any paths starting with this path will be
normalized to::
......@@ -111,7 +111,7 @@ number of names to the test namespace:
``sdist(setup, dest)``
Create a source distribution by running the given setup file and
placing the result in the given destination directory. If the
setup argument is a directory, the thge setup.py file in that
setup argument is a directory, the setup.py file in that
directory is used.
``bdist_egg(setup, dest)``
......
......@@ -146,7 +146,7 @@ It is an error to create a variable-reference cycle:
Getting option buildout:x.
Error: Circular reference in substitutions.
It is an error to use funny characters in variable refereces:
It is an error to use funny characters in variable references:
>>> write(sample_buildout, 'buildout.cfg',
... '''
......@@ -222,7 +222,7 @@ and too have too many or too few colons:
Error: The substitution, ${buildout:y:z},
has too many colons.
Al parts have to have a section:
All parts have to have a section:
>>> write(sample_buildout, 'buildout.cfg',
... '''
......@@ -745,13 +745,13 @@ All gone
def add_distribute_to_dependencies_when_namespace_packages():
'''
Often, a package depends on distribute soley by virtue of using
Often, a package depends on distribute solely by virtue of using
namespace packages. In this situation, package authors often forget to
declare distribute as a dependency. This is a mistake, but,
unfortunately, a common one that we need to work around. If an egg
uses namespace packages and does not include distribute as a depenency,
uses namespace packages and does not include distribute as a dependency,
we will still include distribute in the working set. If we see this for
a devlop egg, we will also generate a warning.
a develop egg, we will also generate a warning.
>>> mkdir('foo')
>>> mkdir('foo', 'src')
......@@ -832,7 +832,7 @@ We do not get a warning, but we do get distribute included in the working set:
>>> print_(handler, end='')
We get the same behavior if the it is a depedency that uses a
We get the same behavior if the it is a dependency that uses a
namespace package.
......@@ -1392,7 +1392,7 @@ def internal_errors():
Getting section data-dir.
Initializing section data-dir.
<BLANKLINE>
An internal error occured due to a bug in either zc.buildout or in a
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
...
......@@ -1844,7 +1844,7 @@ if sys.version_info > (2, 4):
Initializing section x.
Loading zc.buildout recipe entry zc.buildout.testexit:default.
<BLANKLINE>
An internal error occured due to a bug in either zc.buildout or in a
An internal error occurred due to a bug in either zc.buildout or in a
recipe being used:
Traceback (most recent call last):
...
......@@ -2084,7 +2084,7 @@ directory and then use the wacky extension to load the demo package
def distributions_from_local_find_links_make_it_to_download_cache():
"""
If we specify a local directory in find links, distors found there
If we specify a local directory in find links, distros found there
need to make it to the download cache.
>>> mkdir('test')
......@@ -2699,7 +2699,7 @@ def increment_on_command_line():
def test_constrained_requirement():
"""
zc.buildout.easy_install._constrained_requirement(constraint, requitement)
zc.buildout.easy_install._constrained_requirement(constraint, requirement)
Transforms an environment by applying a constraint.
......@@ -2845,7 +2845,7 @@ def cant_use_install_from_cache_and_offline_together():
While:
Initializing.
Error: install-from-cache can't be used with offline mode.
Nothing is installed, even fromn cache, in offline
Nothing is installed, even from cache, in offline
mode, which might better be called 'no-install mode'.
<BLANKLINE>
"""
......
......@@ -237,7 +237,7 @@ directory:
When buildout restarts and the restarted buildout exits with an error code,
the original buildout that called the second buildout also exits with that
error code. Otherwise build scripts can erroneously detect a succesful
error code. Otherwise build scripts can erroneously detect a successful
buildout run even if it failed.
Make a recipe that fails:
......
......@@ -56,7 +56,7 @@ Feature Changes
- Added initialization and arguments options to the scripts recipe.
- Added an eggs recipe that *just* installes eggs.
- Added an eggs recipe that *just* installs eggs.
- Advertized the scripts recipe for creating scripts.
......@@ -97,7 +97,7 @@ Updated to work with zc.buildout 1.0.0b3.
- Extra path elements to be included in generated scripts can now be
set via the extra-paths option.
- No longer implicitly generate py\_ scripts fo reach egg. There is
- No longer implicitly generate "py\_" scripts for each egg. There is
now an interpreter option to generate a script that, when run
without arguments, launches the Python interactive interpreter with
the path set based on a parts eggs and extra paths. If this script
......@@ -122,7 +122,7 @@ Updated to work with zc.buildout 1.0.0b3.
1.0.0a2
=======
Added a custom recipe for building custom eggs using custom distrutils
Added a custom recipe for building custom eggs using custom distutils
build_ext arguments.
1.0.0a1
......
......@@ -14,7 +14,7 @@
"""Setup for zc.recipe.egg package
"""
version = '2.0.0a3'
version = '2.0.1dev'
import os
from setuptools import setup, find_packages
......
......@@ -182,7 +182,7 @@ Let's add an interpreter option:
... interpreter = py-demo
... """ % dict(server=link_server))
Note that we ommitted the entry point name from the recipe
Note that we omitted the entry point name from the recipe
specification. We were able to do this because the scripts recipe is
the default entry point for the zc.recipe.egg egg.
......@@ -483,11 +483,11 @@ each individual script section:
if __name__ == '__main__':
sys.exit(eggrecipedemo.main())
Specifying initialialization code and arguments
Specifying initialization code and arguments
-----------------------------------------------
Sometimes, we need to do more than just calling entry points. We can
use the initialialization and arguments options to specify extra code
use the initialization and arguments options to specify extra code
to be included in generated scripts:
......
......@@ -7,7 +7,7 @@ recipe provides an API that other recipes can use.
A recipe can reuse the egg recipe, supporting the eggs, find-links,
index, and extra-paths options. This is done by creating an
egg recipe instance in a recipes's contructor. In the recipe's
egg recipe instance in a recipes's constructor. In the recipe's
install script, the egg-recipe instance's working_set method is used
to collect the requested eggs and working set.
......
......@@ -25,17 +25,17 @@ define
define.
undef
A comman separated list of names of C preprocessor variables to
A comma-separated list of names of C preprocessor variables to
undefine.
libraries
The name of an additional library to link with. Due to limitations
in distutils and desprite the option name, only a single library
in distutils and despite the option name, only a single library
can be specified.
link-objects
The name of an link object to link against. Due to limitations
in distutils and desprite the option name, only a single link object
in distutils and despite the option name, only a single link object
can be specified.
debug
......@@ -286,7 +286,7 @@ Controlling environment variables
To set additional environment variables, the `environment` option is used.
Let's create a recipe which prints out environment variables. We need this to
make sure the set envirionment variables are removed after the egg:custom
make sure the set environment variables are removed after the egg:custom
recipe was run.
>>> mkdir(sample_buildout, 'recipes')
......@@ -372,7 +372,7 @@ the original value will be restored:
Sometimes it is required to prepend or append to an existing environment
variable, for instance for adding something to the PATH. Therefor all variables
variable, for instance for adding something to the PATH. Therefore all variables
are interpolated with os.environ before the're set:
>>> write(sample_buildout, 'buildout.cfg',
......@@ -460,17 +460,17 @@ define
define.
undef
A comman separated list of names of C preprocessor variables to
A comma-separated list of names of C preprocessor variables to
undefine.
libraries
The name of an additional library to link with. Due to limitations
in distutils and desprite the option name, only a single library
in distutils and despite the option name, only a single library
can be specified.
link-objects
The name of an link object to link against. Due to limitations
in distutils and desprite the option name, only a single link object
in distutils and despite the option name, only a single link object
can be specified.
debug
......
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