If setuptools is installed globally by easy_install then the easy_install.pth gets added to sys.path before PYTHONPATH and the wrong setuptools version is used.

  version-range requirements in a way that caused it to think there
  wasn't a single-version requirement.  IOW, buildout throught that
  versions were being picked when they weren't.

Should have been removed in a previous commit.

Setuptools8

Add option to bootstrap.py to pin setuptools version

Merge branch 'pin_setuptools_in_bootstrap' of github.com:buildout/buildout into pin_setuptools_in_bootstrap

PKG-INFO for setuptools 3.3 has non-ASCII characters.  This causes
two test failures on Python 2, one of them rather unobvious
(testing_bugfix.txt complains about the different number of logging
handlers, of all things).

This simplifies testing all Python versions to 'tox'.

Unfortunately detox cannot be used to run the tests in parallel since
dev.py scribbles directly into the top-level of the source tree (in
bin/).

Tests with Python 3.4 passed on Travis, for a bit.

Contains fix for #198

Fix for the #198 fix

Should fix https://travis-ci.org/buildout/buildout/jobs/39918144

Closes #203

Some background: PEP 453 introduced the 'ensurepip' module to Python 3.4.
'make install' runs 'python3.4 -m ensurepip' which installs setuptools
into site-packages.  Our test suite doesn't like that.  Luckily,
Python's ./configure has an option to disable ensurepip.

Travis thinks something is wrong when the script produces no output in
10 minutes, which leads to sporadic test failures like
https://travis-ci.org/buildout/buildout/jobs/39916822

If PYTHON_VER is not known to the Makefile, don't fall back to
PYTHON_MINOR of 2.7.3, instead ask the user to specify a correct
PYTHON_MINOR explicitly.  Otherwise you get weird failures like #203.

Also allow the user to override PYTHON_MINOR on the `make` command line,
e.g.

    make PYTHON_VER=3.3 PYTHON_MINOR=3.3.6

Closes #202.

Perhaps older versions also support this option, but at least 0.7.2 does not.
So I picked the oldest version I had handy in my buildout egg cache...

A working_set passed into install() is the sign that we're called from
buildout.py to install buildout, setuptools, an extension or a recipe.
Those need the global pkg_resources.working_set, for instance to load entry
points.

So... conflicts with global packages are possible, but they should be ignored
so that we can grab the right versions ourselves. The paths that end up in the
bin scripts that we generate are OK.

Fix for buildout 2.2.3 upgrade/downgrade problems

non-matching versions.

Ignoring version conflicts for buildout and setuptools, this enables
buildout/setuptools upgrades/downgrades after a bootstrap.

Whatever the method we used to find it, cache the result. Not just in one of
the cases. And it makes the method more readable as it doesn't mix functionality

Often it is unclear why buildout takes a long time on something, this logger
statement might make it much clearer

This way it is more clear that we're trying several things one after the
other. And it is nicer to read this way.