Gottfried Ganssauge) (ajung)

  existing buildouts.  Use::

[buildout]
    prefer-final = true

to get the new policy.  The new policy will go into effect in
  buildout 2.

to work with recent change changes to use expanduser rather than
reading $HOME directly.

deterministic output by outputing all of standard output followed
by all of standard error.

No commit message

- The easy_install module install and build functions now accept a
  versions argument that supplied to mapping from project name to
  version numbers.  This can be used to fix version numbers for
  required distributions and their depenencies.

When a version isn't fixed, using either a versions option or using
  a fixed version number in a requirement, then a debug log message is
  emitted indicating the version picked.  This is useful for setting
  versions options.

- Added a remove testing helper function that removes files or directories.

spurious test failures.  I'm not sure this is really necessary.

```------------
- Added a buildout newest option, to control whether the newest
  distributions should be sought to meet requirements.  This might
  also provide a hint to recipes that don't deal with
  distributions. For example, a recipe that manages subversion
  checkouts might not update a checkout if newest is set to "false".

- The recipe-testing support setUp function now adds the name
  *buildout* to the test namespace with a value that is the path to
  the buildout script in the sample buildout.  This allows tests to
  use

>>> print system(buildout),

rather than:

>>> print system(join('bin', 'buildout')),

Bugs Fixed
```

-------

- Paths returned from update methods replaced lists of installed files
  rather than augmenting them.

buildout.

or setuptools, copy the develop eggs to the new buildout's
develop-eggs directory, rather than its eggs directory.

API. This allowed the tests to be simplified somewhat.

This makes things go a little faster, makes errors a little easier to
handle, and allows extensions (like the sftp extension) to influence
more of the process.

Added an environment variable hack to cause the buildout to use a
local empty index when running tests. This allows most of the tests to
be run when offline and doesn't slam pypi at other times.

generated script paths.

Added an arguments option to specify source for arguments to be passed
to entry points.

The sample buildout is now created using the bootstrapping mechanism
and so has a normal layout.

No longer read ~/.buildout/.default.cfg, when running tests.
(We do read a ~/.buildout/.default.cfg when testing that function, but
we manipulate HOME so that we control what is read.)

Added an api for registering tearDown handlers.

Now the test namespace has a helper for creating temporary directories
that are automatically cleaned up.

distributions available. This required working around issues with
easy_install's --upgrade option:

- Upgrade is not recursive. Upgrading a distro doesn't update it's
  dependencies.

- Upgrade doesn't try very hard to avoid searching.  If we require a
  specific version of a distribution, and we already have that
  distribution, there's no point in looking for a newer one.

- easy_install has kind of odd rules for deciding when to look at an
  index.   Now that we use upgrade all the time, easy_install always
  wants to look at an index.

- We get warnings when connecting to index servers, like PyPI that 
  return text/plain not found messages.

We now have much greater control over how dependencies are
managed. We've essentially taken this over from easy_install.

Because we now always talk to an index server and because we want to
control anything we do in a test, many of the tests actually run their
own web servers.

Anyway:

- Now handle upgrades correctly, I think.

- The egg recipe can now install multiple distributions.

- We have the beginnings of offline mode.

- The internal architeture is much cleaner.

- We've merged the easy_install and egglinker modules, tossing
  some superfluois apis in the egglinker module.

buildout) to be used.

shared across projects or working directories.

If a recipe uses any data from other sections, the recipe needs to
update it's data when the recipe is constructed.

Need more discussion of this in the docs.