Require minimum pip version?

With #3691 projects can take control over every version of tooling they interact with from build tools to runtime dependencies. The one thing they can’t control is what version of thing they are installed with. This makes a lot of sense both from a practical standpoint (you can’t run N versions of pip at once for each thing you’re installing) and from a purity standpoint (our standards are not written solely for pip, they’re written so any installer can function instead of pip if desired).

That being said, it’s still useful for projects to require a specific version of pip to install their thing, particularly when installing from sdist as wheels have version numbers and the like to handle compatible/incompatible changes to that spec and there isn’t really much place for logic to happen that people might depend on something pip is providing (or not). However, with sdists there is a lot of feature detection that is going to be happening (does pip support pyproject.toml or not? What about a future abstract build system? what about other, future things we’re not even currently thinking of?). We could just shrug our shoulders and ignore it for now and say that someday we’ll make a sdist 2.0 that also bakes in a version number like wheel does. That is a good solution but will require a fair amount of effort to get done, but as a stop gap we could do something like using the new pyproject.toml file and add our own section to it. Something like:

[tool.pip]
minimum-version = "10"

With this pip could look and if this is declared, it can fail out saying that the project requires pip X.Y in order to build. This of course won’t help all of the old versions of pip, but going forward it could be a useful escape hatch for people.

Thoughts @pypa/pip-committers ?

[pradyunsg]

YAGNI - if someone needs it they can make it

I’m gonna apply this logic and take the liberty of closing this issue.

[chrahunt]

After thinking about it more, I’m not sure there’s anything here that couldn’t be handled by a build backend, assuming we’re talking about sdists. To me that would be a good enough reason not to implement it in pip.

First, this wouldn’t need to be implemented in every backend since a backend wrapper can itself support a tools.wrapper.build-backend key pointing to the “real” backend to be invoked.

Then, if someone did want to explicitly warn or fail based on pip version, the wrapper could recurse up the process hierarchy until it found pip, invoke the equivalent of pip --version, and then do a comparison with tools.wrapper.minimum-pip-version, and fail or trace a warning before invoking tools.wrapper.build-backend. Alternatively I think pip exposes itself in the build environment for installs, so a {sys.executable} -m pip --version might do.

This handles several concerns expressed above:

1. “only pips after this is implemented will understand the option and provide a warning” - as a build backend it would work with any PEP 517 capable pip
2. YAGNI - if someone needs it they can make it
3. fail vs warn - leave it to the backend implementer to decide and if someone disagrees they can make their own backend