When buildout encounter an error, program exists with error code 1, this
should also be the case when exiting from a debugger session when
running with -D option.

/reviewed-on nexedi/slapos.buildout!17

When a recipe is developed in a git working copy, .git administrative
database folder should be ignored, like we did with CVS and svn.

/reviewed-on nexedi/slapos.buildout!14

_install_and_load is slow, using cache saves time when there are many sections.

Contrary to bash, dash filters out environment variables containing
'-' characters. And for example, /bin/sh is dash on Debian.

<rebased>

Now specified patches are automatically applied on required eggs as well.

Useful when recipes generate non-string values to be reused by other
recipes.

  While invoke setup.py certain eggs (like scikit-learn) launch
  cetain custom builds (for cython) using subprocess and sys.executable.

  This commit aims to preserve the sys.path over the runs, even if an
  egg is using subprocess with the same python to build a component of
  the egg.

   This commit is part of fixup the "Add setup-eggs option in zc.recipe.egg:develop."

We want two identical sections at different URL to be able to produce
same signature. This is feature is useful for slapos.recipe.cmmi's
shared parts.

Rebase instructions:
- squash with "apply "Support ${:_profile_base_location_}."

Add referred parts' hash strings in __buildout_signature__, that invokes rebuild of a part when one of its (recursive) dependencies are modified.

Also remove duplicates and sort entries in __buildout_signature__.

Also, updating a part does not put it anymore at the end of the list of
installed parts, that was making .installed.cfg too big.

In SlapOS, bootstrap is called each time software release is invoked and
we do not want to delete develop-eggs directory.

This reverts commit 55d76b34.

https://bugs.launchpad.net/zc.buildout/+bug/144228

Even though such configuration is wrong...

Currently only zc.recipe.egg:custom supports setting environment
variables, and zc.recipe.egg:develop does not.

My motivation for allowing setting environment in :develop is
wendelin.core

    https://lab.nexedi.cn/nexedi/slapos/blob/b5faab3b/component/wendelin.core/buildout.cfg

There we have [wendelin.core] part which installs released egg from
pypi, and [wendelin.core-dev] part which installs wendelin.core from
its latest git version via zc.recipe.egg:develop .

The problem is, wendelin.core for setup.py to work, needs git available,
and with slapos we usually don't have git available on base system, so
we build it by our own and do something like

    [wendelin.core-dev]
    recipe = zc.recipe.egg:develop
    environment = wendelin.core-dev-env

    [wendelin.core-dev-env]
    # wendelin.core-dev needs git to build
    PATH = ${git:location}/bin:%(PATH)s

and the problem is environment does not currently work for
zc.recipe.egg:develop, and thus git is not found -> build fails.

~~~~

In order to support environment in :develop, we just move environment
setting/restoring bits from Custom to Base, and provide Base.install() which
uses this bits. Custom & Develop .install() becomes ._install() which gets
hooked into Base.install() .

I've tested the patch only manually, because currently automated tests are
broken in a lot of places for slapos.buildout and zc.recipe.egg .

/cc @kazuhiko, @Tyagov

- Support on the fly patches in zc.recipe.egg by ``EGGNAME-patches``,
  ``EGGNAME-patch-options``, ``EGGNAME-patch-binary`` (or
  ``patch-binary``) and ``EGGNAME-patch-revision`` options.

- Support on the fly patches in zc.recipe.egg:custom by ``patches``,
  ``patch-options``, ``patch-binary`` and ``patch-revision`` options.
  (options ``EGGNAME-*`` are also supported as well).

extends can be interpreted as inheritance in OOP, but the original
behaviour was against what is commonly (always?) seen everywhere.

It is however good practice a file extends all files it needs directly
(and only them). Then if two files A & B (possibly unrelated) extends
the same third C, A was unable to overrides C values. It was even
error-prone because someone who don't use B yet could override C values
in A and later extending B would break A.

For some of our common use cases, this new algorithm is also 9x faster
(time to annotate: ~2.3s with -> ~.29s).

Other changes:
- ~/ is now expanded for non-url extends.
- An absolute (non-url) path is not longer treated like a local path
  if the base is a url.
- Better path/url normalization.

Rebase instructions:
- squash with "Chomp ../ from beginging of filenames"
- split and apply "Support ${:_profile_base_location_}." after

Sqaushed with

Chomp ../ from beginging of filenames.

In order to have as canonical as possible paths, chomp ../ from filenames and
recalculate base.

--setuptools-version and --buildout-version options in bootstrap script still have the priority.

One big issue in commit e129e187 is that the
initial value of buildout_and_setuptools_path can cause buildout to use a lot
of CPU at startup. The following change would help:

    def buildout_and_setuptools_path():
        r = [get_python_lib(standard_lib=1)]
        for d in pkg_resources.working_set:
            d = d.location
            if d not in r:
                r.append(d)
        return r[1:]
    buildout_and_setuptools_path = buildout_and_setuptools_path()

but initializing buildout_and_setuptools_dists also takes time to compute,
and it's only used for bootstrap.

Because the commit is not required anymore since setuptools 36, it's easier
for us to revert partially, so we can keep applying our patches.

(cherry picked from commit 18964211)

(cherry picked from commit 73b1377c)

PyPI redirects HTTP to HTTPS by default now so using HTTPS directly
avoids the potential for that redirect being modified in flight,
helping prevent MITM attacks.

Fixes #114.

(cherry picked from commit fac9979f)