Having a runtime dependency on pip: make it explicit whether this is supported or not

What’s the problem this feature will solve?

See https://discuss.python.org/t/pip-plans-to-introduce-an-alternative-zipapp-deployment-method/17431/22 for context. Basically, people are suggesting that if we distribute a zipapp version of pip and as a result, environments without pip become more common, they will add pip as a runtime dependency to force the environment to contain pip.

While locating a copy of pip to run programmatically is a non-trivial problem (this is one of the reasons we’re hesitating over making an official zipapp), if projects start to add a dependency on pip, this will block the option of finding other, less disruptive, ways of achieving pip-less environments[^1].

In addition, pip has no programmatic API, and the normal use of declaring a dependency is for your code to call a library from Python. People don’t declare a dependency on bzr so they can run bzr commands using subprocess, any more than they do for git. Why should pip be different?

[^1]: Which I believe are important - py -m venv takes 6 seconds on my machine, whereas py -m venv --without-pip takes under 0.1 second.

Describe the solution you’d like

Explicitly state in the documentation, alongside the statement that pip has no supported Python API, that we don’t support including pip in a project’s runtime dependencies.

Alternative Solutions

Leave our position unstated and implicit.

Additional context

Some of the alternative approaches to relying on pip being in the environment include:

1. Projects assume the existence of a pip command, and run that (the same as they would for something like git). This is a reversion of our existing advice that people should run pip via subprocess.run([sys.executable, "-m", "pip"]) which would be frustrating churn for our users. Otherwise, though, it’s exactly what we’d expect people to do for any other command line tool like git.
2. Projects add a configuration option to allow the user to state how pip should be invoked (with the default remaining python -m pip, at least for now). Not all projects have a configuration system, so this might be a bigger change than is ideal.
3. Projects try to auto-discover a suitable pip command. This is likely both costly and error prone.

So I think that relying on pip being in the environment may need to remain the norm for now. And that may well impact the advisability of shipping an official zipapp. However, I still don’t think that projects adding a dependency on pip is a good idea.

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

Yeah, it makes a lot of sense for tools like that which would get installed using pipx to depend on pip. I’m happy to withdraw this suggestion on that basis.

One point I made over on Discourse - pipx exposes a shared pip in every venv it manages (to reduce the overhead of installing pip everywhere). It’s not immediately obvious to me how that would interact with a package that depends on pip (probably perfectly fine, but if the shared pip doesn’t match the application’s dependency spec things might get tricky). It’s probably something you should test before relying on it. Conversely, of course, it would now make a lot of sense for pipx to do the same, and install a private copy of pip and use --python. Maybe I’ll look at that next 🙂

[uranusjr]

needing to know the location of Pip and be able to guarantee it exists in an environment is Conda

Wouldn’t this be covered by Conda? Conda’s pip is a re-distribution, and re-distributors by definition can have different rules they can maintain themselves. This is similar to how pip can be installed with apt install python3-pip, and we certainly won’t go so far to say it’s a wrong thing for apt to support, just not for us to support. That’s what I understand from this.