easy_install: add support for installing from wheels

[benoit-pierre]

Wheels are installed as eggs, so each install is self-contained and multiple versions of the same package can be installed at the same time.

Limitations:
- headers are not supported: since they are extracted to the self-contained egg directory, and not copied to the system includes directory
- resulting egg metadata requirements have their markers stripped: in practice, since eggs' name include the Python version (so using python2 setup.py ... followed by python3 setup.py ... will work if one of setup_requires' requirement has one or more Python 3 specific dependencies).

Note: glib.c and pep425tags.py were copied from pip (not wheel, for manylinux support), and modified for Python 2.6 compatibility.

[benoit-pierre]

I forgot to mention the rational for this PR: with development of PEP 517/518 support in hiatus, it might be a while before there's an alternative for setuptools' setup_requires. But some Python packages are not installable from source (and don't provide eggs), yet can be used for building other packages: for example PyQt5 is only installable from wheel, and provide some tools needed for generating UI files (pyrcc5, pyuic5).

[benoit-pierre]

Since headers are not correctly supported, this patch could introduce some issues for users that still rely easy_install instead of pip, maybe the main easy_install module/script should be removed?

Alternatively, wheels could be opt-in when using easy_install directly (but always enabled when internally used by setuptools).

[jaraco]

Note: glib.c and pep425tags.py were copied from pip (not wheel, for manylinux support), and modified for Python 2.6 compatibility.

I wonder if it makes sense to extract those modules into packages that could then be vendored and shared by both codebases. Otherwise, we'll inevitably end up dealing with the divergence of these two modules (which has already happened). At the very least, I'd like for each module to have a header describing where it's canonical source resides and keep a log of changes against that source).

It's a little ironic that Setuptools has been waiting for pip to drop Python 2.6 support but now that it's potentially adopting pip modules, it has to restore Python 2.6 support. :( I think that's a sign that we should just merge and release the drop-py26 branch. I'll do that.

[benoit-pierre]

Note: glib.c and pep425tags.py were copied from pip (not wheel, for manylinux support), and modified for Python 2.6 compatibility.

I wonder if it makes sense to extract those modules into packages that could then be vendored and shared by both codebases. Otherwise, we'll inevitably end up dealing with the divergence of these two modules (which has already happened). At the very least, I'd like for each module to have a header describing where it's canonical source resides and keep a log of changes against that source).

As part of packaging maybe? See pypa/packaging#83

It's a little ironic that Setuptools has been waiting for pip to drop Python 2.6 support but now that it's potentially adopting pip modules, it has to restore Python 2.6 support. :( I think that's a sign that we should just merge and release the drop-py26 branch. I'll do that.

👍

[jaraco]

As part of packaging maybe?

Yes, that sounds like the right solution. I'm okay with vendoring the modules here until they're released with packaging, especially if there's a comment reminding us that that's what's happening.

Also, Python 2.6 support is now dropped.

[benoit-pierre]

I removed the changes for Python 2.6 support, and updated glibc.py and pep425tags.py to indicate their provenance.

[jaraco]

Looks good to me. Do you mind adding the changelog entry and cutting the release (per https://github.com/pypa/setuptools/blob/master/docs/releases.txt)?

[benoit-pierre]

OK, minor or major? I think this is a pretty big change considering the impact on easy_install's behavior.

[jaraco]

If it’s backward incompatible, meaning that some users might not be able to use setuptools as they did before without intervention, then a major bump is indicated. If it’s only a bug fix for existing behavior, then it’s a patch bump. Otherwise, it’s a minor bump. The Semver bump doesn’t consider the size of the change, only the scope of the change.

[benoit-pierre]

Well, I was concerned by the fact that headers are not completely supported (not installed to include directory), but a quick test shows that building an egg with bdist_egg does not even include the header, so switching to using a wheel would not be a backward incompatible change. Minor version bump it is.