New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

easy_install: add support for installing from wheels #1200

Merged
merged 1 commit into from Nov 26, 2017

Conversation

Projects
None yet
2 participants
@benoit-pierre
Member

benoit-pierre commented Nov 17, 2017

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

This comment has been minimized.

Member

benoit-pierre commented Nov 17, 2017

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

This comment has been minimized.

Member

benoit-pierre commented Nov 19, 2017

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

This comment has been minimized.

Member

jaraco commented Nov 20, 2017

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

This comment has been minimized.

Member

benoit-pierre commented Nov 20, 2017

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

This comment has been minimized.

Member

jaraco commented Nov 20, 2017

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.

easy_install: add support for installing from wheels
Note: 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
- resulting egg metadata requirements have their markers stripped

@benoit-pierre benoit-pierre force-pushed the benoit-pierre:wheels_support branch from c089487 to 118edbb Nov 26, 2017

@benoit-pierre

This comment has been minimized.

Member

benoit-pierre commented Nov 26, 2017

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

@jaraco

jaraco approved these changes Nov 26, 2017

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

This comment has been minimized.

Member

benoit-pierre commented Nov 26, 2017

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

@jaraco

This comment has been minimized.

Member

jaraco commented Nov 26, 2017

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

This comment has been minimized.

Member

benoit-pierre commented Nov 26, 2017

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.

@benoit-pierre benoit-pierre merged commit 97ff22f into pypa:master Nov 26, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details

@benoit-pierre benoit-pierre deleted the benoit-pierre:wheels_support branch Nov 26, 2017

@jmbowman jmbowman referenced this pull request May 16, 2018

Merged

Add tests for PEP 425 support #1369

2 of 2 tasks complete
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment