Add support for pip install --only-deps.

[shoeffner]

This commit follows the agreed interface in 1:

pip install --only-deps .  # project.dependencies
pip install --only-deps .[doc]  # project.dependencies and project.optional-dependencies

If --only-deps or its longform --only-dependencies is provided, neither the explicitly requested packages nor the build dependencies are installed, instead only the "runtime" dependencies are used.
--only-deps and --no-deps are mutually exclusive and pip will refuse to install anything if both are specified.

Because --only-deps does not install build dependencies, no implicit or dynamic dependencies can be managed this way, that means a build tool cannot automatically install more dependencies by executing additional code.

First part of #11440.

[shoeffner]

Okay, looks like the legacy resolver requires a similar treatment or has to throw an error. I'll see what I can do :-)

[notatallshaw]

FYI, it's completely fine to ban the user from providing only deps and use legacy resolver, if that makes things simpler.

Recently there is movement on dropping the legacy resolver.

[shoeffner]

The main failure reason is that I missed the fact that the options-object does not always have the proper values (i.e., options.only_dependencies is not available unless specified). To make it work, I first considered getattr(options, 'only_dependencies', False), but after sleeping over it, the cleaner solution seems to be to also add the option to the commands download, lock, and wheel.

While the scope of the issue was to provide --only-deps for install, I believe adding it to the related commands is better than any workaround which would be replaced in the future again.

I will do that today after work.

[sbidoul]

Thanks for working on this!

A couple of comments/questions.

[shoeffner]

I cannot reproduce the CI failures locally:

FAILED tests/unit/metadata/test_metadata.py::test_trailing_slash_directory_metadata[/path/to/foo.egg-info] - importlib.metadata.MetadataNotFound: No package metadata was found.
FAILED tests/unit/metadata/test_metadata.py::test_trailing_slash_directory_metadata[/path/to/foo.egg-info/] - importlib.metadata.MetadataNotFound: No package metadata was found.

But they seem to be failing on the main branch as well.

[sbidoul]

also add the option to the commands download, lock, and wheel.

Absolutely, that has to be done at the same time.

[shoeffner]

I rebased the branch on the current main, I hope that resolves then Python 3.15 issues of the CI pipeline.

I also added basic function tests to wheel, download, and lock for the feature.

[sbidoul]

Thanks! I did some tests and it works as expected. The implementation is simple and contained which is great!

A few comments to address, but this looks like it's almost ready.

[shoeffner]

Thanks for the thorough review, @sbidoul, your feedback was great and I believe it helped a lot to improve the PR!
Let me know if there is more to address or not :)

If not, I can rebase and squash the commits to be a bit more concise and mark the PR as ready.

[shoeffner]

I have squashed and rebased the PR and marked it as "Ready for review". Let me know if there's more I can address :)

(P.S.: As mentioned in the issue, don't feel pressured, I am in no hurry :) )

[sbidoul]

@shoeffner I worry I sent you on a difficult track with assert_not_installed, as the original assert_installed is old and not super robust itself. A better way would be to test for the absence of site-package/{package}-*.dist-info (assuming the package name is normalized). Sorry about that.

Alternatively, examining the installation report of pip install --quiet --dry-run --report - is also a possibility.

[shoeffner]

Haha, no need to worry. I will take a look into that, thanks for the suggestion!

[sbidoul]

@shoeffner a quick note that July and 26.2 is approaching. So if you find the time to have a last look at the tests in the coming couple of weeks, this can likely make it into 26.2.

[ichard26]

I'd like to include this in pip 26.2 if it is ready by the end of the month. I still need to perform an in-depth review, but on the surface, the proposed UI looks good to me. I'll need to think about the UI a bit more since I haven't thought about this feature in ages (and we're growing a lot of complexity¹ around requirements which makes me uneasy).

Footnotes

1. To be clear, this isn't your fault. It's just inherent complexity from pip growing organically over the decades. pip's pylock support is also in the same boat. ↩

[shoeffner]

Sorry for the slow response time!

• I rebased the branch
• I changed assert_not_installed to check for the relevant dist-info folder per @sbidoul's suggestion and adjusted the relevant tests (this way, there's no difference for editable / non-editable installs, thus they deliver the same error message)
• I fixed the black formatting by using --target-version py314. Surprisingly, the pre-commit checks always passed, while the CI did not. I guess I borked a part of my local setup.

[sbidoul]

A couple of documentation suggestions but otherwise this looks good to me. Thanks for this work!

[sbidoul]

"handle" sounds a little bit strange, but I see why you use this as this option is used for install, wheel, download and lock. I don't have a better idea.

[shoeffner]

Maybe a different sentence structure such as "Take only the dependencies ... into account" could work?

[shoeffner]

I changed it accordingly, but am happy to change it to any other good wording.