Provide get-pip.py versions for all python versions

[xavfernandez]

Each time pip drops the support for some version of python, users need to update their script from https://bootstrap.pypa.io/get-pip.py to https://bootstrap.pypa.io/X.Y/get-pip.py.

I'm wondering if we shouldn't directly provide https://bootstrap.pypa.io/X.Y/get-pip.py for all existing (and recent) python versions.

That would currently mean to provide https://bootstrap.pypa.io/3.6/get-pip.py, https://bootstrap.pypa.io/3.7/get-pip.py, https://bootstrap.pypa.io/3.8/get-pip.py, https://bootstrap.pypa.io/3.9/get-pip.py & https://bootstrap.pypa.io/3.10/get-pip.py that would be copies of https://bootstrap.pypa.io/get-pip.py.

Users would then be able to directly use the get-pip.py script version matching their python version.

[pfmoore]

As an alternative, get-pip.py could check the Python version, and if it's not a supported version, print a message directing the user to download the appropriate https://bootstrap.pypa.io/X.Y/get-pip.py script and use that, and then exit.

[bsiegel]

Perhaps get-pip.py could redirect to the version that works for whichever version if Python is requesting it, that way users and build systems would not all need to code in the logic to select the correct URL for the correct Python version.

[pradyunsg]

We can't have redirects, since a common mechanism is using curl, which won't be happy with redirects.

[webknjaz]

@pradyunsg curl -L can follow redirects just fine.

[pfmoore]

But the suggestion was "redirect to the version that works for whichever version if Python is requesting it" and if you're requesting it with curl, the server has no way to know which version of Python is requesting it (because it's not being requested by Python!)

[bsiegel]

Yep, sure - I should have been more clear, I don't think HTTP redirects specifically are the mechanism to achieve this. Just that in concept, if the initial script could function as a sort of stub, determine the Python version that is executing it, and then load the appropriate full version of the get-pip script, that would provide significant value. However, I realize even that may not be viable because the get-pip script is intentionally kept simple (e.g. it doesn't attempt to do any network operations for example, and adding such a mechanism would add new complexity, failure modes, etc).

An alternative that might provide similar value would be to provide versioned copies of the script not by their interpreter version, but by the version of pip they install (e.g. https://bootstrap.pypa.io/21.0/get-pip.py). Extending this idea, there is prior art we can look at from Javascript CDNs which allow the requester to include a version specifier in the URL. For example, this is how jsDelivr handles versioned URLs:

// load the specific version v3.2.1
https://cdn.jsdelivr.net/npm/jquery@3.2.1/dist/jquery.min.js

// load the latest v3.2.x version
https://cdn.jsdelivr.net/npm/jquery@3.2/dist/jquery.min.js

// load the latest v3.x version
https://cdn.jsdelivr.net/npm/jquery@3/dist/jquery.min.js

// omit the version completely to get the latest one
https://cdn.jsdelivr.net/npm/jquery/dist/jquery.min.js

This can be pretty easily managed by simply populating the appropriate directory structure with copies of the scripts, and publishing updates to the right places. It's only marginally more complex than the current approach, and the "deployment" could be done in a couple lines of shell script. But it would provide a lot of value for e.g. reproducible builds, CI maintainers, etc.

[pradyunsg]

I don't think jsDelivr's model works for us -- we don't follow SemVer and, realistically, "get me something for my Python version" is much easier to support than get-me-a-specific-version.

---

Now that the script for handling generation has been modernised in #85 and #100, this should be significantly easier to do. :)

[uranusjr]

I think it’s a good idea to provide scripts for all versions, even if they are just duplicates to the main get-pip.py. Provision projects currently need to always refer to the versionless get-pip.py, which creates problems when the user provision with an old version of the tool after a Python version is dropped by pip, and the tool has no way to address this in a forward-compatible way.

If we provide scripts to all Python versions, tools can instead have something like

versioned_url = "https://bootstrap.pypa.io/{v.major}.{v.minor}/get-pip.py".format(v=sys.version_info)
script_path = _download_script(versioned_url)
subprocess.run([sys.executable, str(script_path)], check=True)

that’s guaranteed to work no matter in the future.

[pradyunsg]

Yup yup. That's why I've been making all the changes in this repository recently. ;)

[pradyunsg]

Alrighty, we can now do this. It's a matter of updating the following dictionary:

get-pip/scripts/generate.py

Lines 20 to 56 in 5a43acd

	SCRIPT_CONSTRAINTS = {
	"default": {
	"pip": "",
	"setuptools": "",
	"wheel": "",
	},
	"2.6": {
	"pip": "<10",
	"setuptools": "<37",
	"wheel": "<0.30",
	},
	"2.7": {
	"pip": "<21.0",
	"setuptools": "<45",
	"wheel": "",
	},
	"3.2": {
	"pip": "<8",
	"setuptools": "<30",
	"wheel": "<0.30",
	},
	"3.3": {
	"pip": "<18",
	"setuptools": "",
	"wheel": "<0.30",
	},
	"3.4": {
	"pip": "<19.2",
	"setuptools": "",
	"wheel": "",
	},
	"3.5": {
	"pip": "<21.0",
	"setuptools": "",
	"wheel": "",
	},
	}

And updating the logic for how we determine the "minimum supported version" for the "default" get-pip.py script:

get-pip/scripts/generate.py

Line 159 in 5a43acd

major, minor = map(int, sorted_python_versions[-1].split("."))

---

The open question here is: how do we want to handle constraints for the versions of Python where we haven't dropped support yet? We do however need to care about the pip version, since that determines whether the script can run on the Python interpreter.

It's not a big deal for setuptools and wheel pins, since the newer versions of pip are Python-Requires aware -- so keeping them as empty strings is fine.

[pradyunsg]

Oh, I just realized... we do get the requires_python key in the JSON from PyPI -- we can use that information to populate the pip pin! We can probably remove the pip key from this mapping if we use this information!

Given that we don't need a setuptools/wheel pin anymore, that whole hard-coded-bits-of-information can be removed too, making this much easier to use as well.