Pip V22 install --report in Json to get requirements

CAM-Gerlach · August 30, 2022, 3:44am

Somewhat related re: pip programmatic invocation

github.com/pypa/pip

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

opened 08:01AM - 23 Jul 22 UTC

closed 10:24AM - 30 Aug 22 UTC

pfmoore

type: feature request

### 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 - [X] I agree to follow the [PSF Code of Conduct](https://www.python.org/psf/conduct/).

and