Drop run-time version constraints for modern Pip #211
Conversation
edmorley
force-pushed
the
drop-version-constraints
branch
2 times, most recently
from
f710fdb
to
91fca47
Compare
|
@pradyunsg I don't suppose you'd have a spare moment to review? I'd like to open a PR to resolve #200, but it will conflict this this PR, so it would be great to get this PR merged before I do that if possible :-) |
|
Gentle two month nudge for review :-) |
|
I see this now @edmorley! 🙈 To be honest, I'm unlikely to have free cycles to take a closer look and land this anytime soon (I wanna let #213 get through before coming back around to this, and I go on vacation starting this weekend... which means this will slip past my visual range soon-enough!). I did take a cursory look now and it LGTM based on that -- but I'd like to take a proper look before landing this. Alternatively, someone else with the commit bit is welcome to land this! |
|
@pradyunsg Totally understand, no worries! I don't suppose we could merge this separate typo fix PR in the meantime (so I can then rebase this PR on top of main after it merges): |
edmorley
force-pushed
the
drop-version-constraints
branch
3 times, most recently
from
c6be8a0
to
64d90fd
Compare
Modern Pip (v9.0.0+) supports `Requires-Python` and so automatically takes the current Python version into account, when determining the latest version of packages that can be installed. As such, for modern Pip we don't need to specify version range constraints for the pip/setuptools/wheel versions passed to the `pip install` at `get-pip.py` run-time. This is the first step towards being able to remove `SCRIPT_CONSTRAINTS` and rely purely on `Requires-Python` metadata, per: pypa#88 (comment) I've intentionally left the "figure out what Pip version to embed in the template" part of template generation alone for now to keep the PR smaller, and have only changed the run-time `pip install` parts. I had to add a new `pre-9.py` template file (created as a copy of `pre-10.py`), since it's only pip<9 that needs the various version constraint references in the template (and otherwise anything else that used `pre-10.py`, such as Python 2.6, would have had redundant version constraints). The new `pre-9.py` template is only used for Python 3.2.
edmorley
force-pushed
the
drop-version-constraints
branch
from
64d90fd
to
ea6890a
Compare
|
I've rebased on |
Modern Pip (v9.0.0+) supports
Requires-Pythonand so automatically takes the current Python version into account, when determining the latest version of packages that can be installed.As such, for modern Pip we don't need to specify version range constraints for the pip/setuptools/wheel versions passed to the
pip installatget-pip.pyrun-time.This is the first step towards being able to remove
SCRIPT_CONSTRAINTSand rely purely onRequires-Pythonmetadata, per: #88 (comment)I've intentionally left the "figure out what Pip version to embed in the template" part of template generation alone for now to keep the PR smaller, and have only changed the run-time
pip installparts.I had to add a new
pre-9.pytemplate file (created as a copy ofpre-10.py), since it's only pip<9 that needs the various version constraint references in the template (and otherwise anything else that usedpre-10.py, such as Python 2.6, would have had redundant version constraints). The newpre-9.pytemplate is only used for Python 3.2.