The only effect of the import is that ez_setup's use_setuptools() function
does a sys.exit(2) when the required version doesn't match the site package's
one.

If the import doesn't happen, use_setuptools() will just grab a matching
version if the site package's version is too old.

Note that the latest ez_setup.py scripts default to requiring the very latest
setuptools version! So --allow-site-packages isn't really very useful this
way.

The python 2/3 try/except for urlopen() was combined with an optional import
of setuptools and pkg_resources.

The end result is that IF you're on python2 and IF you use
--allow-site-packages and IF you don't have setuptools installed, THEN you'll
get an import error for the python 3 urlopen...

All options' help text now start with a capital letter.

Use local ez_setup.py if one exists; add --setuptools-download-base option

The pull request itself contains a change that should not be applied.

Run easy_install with specified setuptools_version, same change as #232 

Run easy_install with specified setuptools_version

Use 'rcN' for release candidate versions in tests

Our VersionConflict handling could result in an UnpackError when rendering

Potential fix for https://github.com/buildout/buildout/issues/217

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.

Recent setuptools versions changed the canonical spelling of release
candidate versions from 'cN' to 'rcN'.  Using the older spelling causes
a UserWarning about the version requiring normalization, and test
failures where the expected output contains a different (normalized)
version number.

For the record, the UserWarning looks like this:

/home/mg/src/buildout/eggs/setuptools-11.3.1-py2.7.egg/setuptools/dist.py:283:
UserWarning: The version specified requires normalization, consider
using '1.2rc1' instead of '1.2c1'.

and the failures can be seen at
https://travis-ci.org/buildout/buildout/jobs/46215472

Don't assume pkg_resources is a module.

In setuptools < 8.3 pkg_resources.py was a module, so

    import pkg_resources
    print(pkg_resources.__file__)

would print something like

    /home/mg/src/buildout/eggs/setuptools-8.0.4-py2.7.egg/pkg_resources.py

Starting from setuptools 8.3 pkg_resources became a package, so the
above code prints

    /home/mg/src/buildout/eggs/setuptools-11.3.1-py2.7.egg/pkg_resources/__init__.py

which means a single os.path.dirname() is no longer sufficient to find
the location of the .egg file/directory.

I'm pretty sure 'setuptools' itself was always a package, so use two
os.path.dirname()s on setuptools.__file__ to find the .egg location more
reliably with both old and new setuptools versions.

Fixes https://github.com/buildout/buildout/issues/227

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

On Windows, `sys.prefix` is a site-package directory, i.e. for a
standard installation `C:\Python27`. The code path for `not
allow_site_packages` removed *everything* from `sys.path` that contains
*any* of the the site-packages directories as reported by
 `site.getsitepackages`, which on Windows removes all pathes below
 `sys.prefix` from `sys.path`.

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