"dist" can be a PathMetaData instance, req.key is nicer. The latter has a .lower()...

Before you'd get a simple output like:

    Installing django.
    While:
      Installing django.
    Error: The requirement ('Django>=1.7') is not allowed by your [versions] constraint (1.6.6)

... which would mean you'd have to grep in all your requirements'
sub-requirements which package actually requires the offending "django>=1.7"

With this change you'll get a much more helpful output right before the error:

    Installing django.
    version and requirements information containing django:
      [versions] constraint on django: 1.6.6
      Base installation request: 'sso', 'djangorecipe'
      Requirement of djangorecipe==1.10: Django
      Requirement of djangorecipe==1.10: zc.recipe.egg
      Requirement of djangorecipe==1.10: zc.buildout
      Requirement of sso: django-nose
      Requirement of sso: django-mama-cas
      Requirement of sso: django-debug-toolbar
      Requirement of sso: django-auth-ldap
      Requirement of sso: Django<1.7,>=1.4.2
      Requirement of lizard-auth-server: django-nose
      Requirement of lizard-auth-server: django-extensions
      Requirement of lizard-auth-server: Django<1.7,>=1.6
      Requirement of django-nose: Django>=1.2
      Requirement of django-nose: nose>=1.2.1
      Requirement of django-mama-cas: requests==1.1.0
      Requirement of django-debug-toolbar: sqlparse
      Requirement of django-debug-toolbar: Django>=1.7
      Requirement of django-auth-ldap: python-ldap>=2.0
      Requirement of django-auth-ldap: django>=1.1
      Requirement of translations: Django>=1.4
      Requirement of django-extensions: six>=1.2
    While:
      Installing django.
    Error: The requirement ('Django>=1.7') is not allowed by your [versions] constraint (1.6.6)

This makes it much easier to spot the cause (in this case
django-debug-toolbar).

There *are* some unrelated packages in here because I'm doing a textual
comparison. The advantage is that it is very robust. And extracting the right
package name from requirements without messing things up is harder to get
right and takes more code.

- Adjusted the now-clearer error.
- Removed error log message as that's now in the actual error message

Previously:

    The constraint, 1.6.6, is not consistent with the requirement, 'Django>=1.7'.
    While:
      Updating django.
    Error: Bad constraint 1.6.6 Django>=1.7

Now:

    While:
      Installing django.
    Error: The requirement ('Django>=1.7') is not allowed by your [versions] constraint (1.6.6)

The original message said "bad constraint". No, the constraint is not
necessarily bad. It only conflicts with some other package's requirement.

The new message tells you that "constraint" means "your own [versions]
list".

[ci skip]

[ci skip]

Fix #279 on windows

[ci skip]

[ci skip]

Same as #277, but with test and changelog entry

The base dir ("develop = .") should be relativized, too, but currently isn't.
This test proves that it doesn't work (it will be fixed by #277)

For example when you use the develop option like:

  [buildout]
  develop= .

Fixed winbot test. Didn't think about -script and .exe

See http://winbot.zope.org/builders/zc_buildout_dev%20py_270_win64%20master/builds/1149/steps/test/logs/stdio

[ci skip]

[ci skip]

distutils scripts for develoment eggs are also installed

-x means "do not install scripts" and we're doing that now.
So the test needed to be adjusted.

Upgraded version pins

This only impacts testing.
Note that
VersionConflict: (zc.recipe.testrunner 2.0.0 (/Users/reinout/.buildout/eggs/zc.recipe.testrunner-2.0.0-py2.7.egg), Requirement.parse('zc.recipe.testrunner==1.3.0'))
means you have to remove .installed.cfg. Pinning a recipe version in a 'recipe=' line isn't handy.

fix for win32 '#!"python"' vs '#!python' shebang

A pip issue prevents installation of wheels with ``.egg`` in their name...

[ci skip]

[ci skip]