Install requirements from pyproject

[ja2142]

closes #11440 ?

This is more of a proof of concept, I can try improving it and adding tests if this approach is deemed to be ok.

Since actual --only-deps option opens up a lot of rabbit holes (when installing anything other than .) and installing only dependencies of some remote package for example doesn't seem to be useful to me, this PR just handles dependencies from pyproject.toml in -r, e.g. pip install -r pyproject.toml.

I guess this is technically a breaking change, but I don't know what kind of person keeps their requirements in non-toml format in a file named pyproject.toml. -r pyproject.toml is also apparently what uv already does.

Only main dependencies (the ones in project.dependencies) are handled (for now?). Trying to do install -r pyproject.toml on pyproject with dynamic dependencies results in an error.

As is, I believe this PR is enough to address at least my use case for this: it allows caching dependency layers in docker easily, without additional tools.

[notatallshaw]

Hey @ja2142 thanks for opening a PR against pip.

There are some important design questions to consider on if this is the right choice of design from both a UX perspective (same flag or a different flag as -r?) and a technical perspective (should pip parse the dependencies or request them from the build backend?).

Please be aware all maintainers are currently volunteers, so we don't tend to have a lot of time to spend on pip, and it may be quite some time before any of weighs in on this.

[ja2142]

Thanks for a response.

I lean slightly towards -r pyproject.toml, it's short, seems fairly self explanatory to me, and it's what uv uses, some consistency wouldn't hurt. But if there are reasons against it, something like --requirements-from-pyproject is fine by me (maybe it could be a bit shorter).

As far as I understand from discussion on #11440, there is no way to get dependencies from the build system with a guarantee that build (or part of build) won't be invoked, which would likely result in a failure when used in a container with just pyproject.toml. Reading comments on #11440, it seems that reading pyproject.toml directly is a reasonable solution for static dependencies.