Support selective ignoring of package dependencies

[skieffer]

Greetings, and thanks for this great library.

This is another PR addressing the "exclude-type" operations discussed in #333, and it is complementary to #1509.

#1509 lets you say: "After resolving the whole dependency graph, delete these nodes out of it."

This PR lets you say two different things:

1. "I want package A without requiring any of its dependencies." (cf. pip's --no-deps)

2. "The authors of package A made it depend on B and C. But when I use A I don't need C. So treat A as if it didn't depend on C."

Usage looks like:

pip-compile --cut-deps A

or

pip-compile --cut-deps A:C

respectively.

Critically, we are not deleting nodes from the dependency graph, we are deleting edges, and refusing to follow them.

This means we are happy for some other package to bring a node into the graph, should that ever happen. So with this graph,

             A      (X)
           /   \   /
          B      C
         / \    / \
        D   E  F   G

as long as I depend only on A, I want pip-compile --cut-deps A:C to keep C, F, G out of my installation.
However, if some day I add X to my project, then I'm happy for C, F, G to come in.

Contributor checklist

• Provided the tests for the changes.
• Assure PR title is short, clear, and good to be included in the user-oriented changelog

Maintainer checklist

• Assure one of these labels is present: backwards incompatible, feature, enhancement, deprecation, bug, dependency, docs or skip-changelog as they determine changelog listing.
• Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

[skieffer]

Rebased on 6.8.0. The --cut-deps feature is now only in the LegacyResolver.

[atugushev]

Just out of curiosity, what's your real-world use case for this feature?

Rebased on 6.8.0. The --cut-deps feature is now only in the LegacyResolver.

Note the legacy resolver is deprecated and will be removed soon, which is why we don't accept new features related to it.

[skieffer]

Thanks for your interest. My real-world use case is the gremlinpython package. It declares a dependency on aiohttp and nest_asyncio, but there are ways to use it that don't require these at all (or their many recursive requirements).

So when I install gremlinpython, I'd like to cut the dependency edges

gremlinpython --> aiohttp
gremlinpython --> nest_asyncio

meaning, "I don't want aiohttp or nest_asyncio today. Tomorrow, I may need them for some other reason. Until then, I don't want them."

• I noted a similar case here.
• My case is discussed here.

Basically, package maintaners sometimes fail to use extras_require. As package consumers, we should still have options to exclude dependencies that are inessential for our present use case, without excluding them from future use-cases.

[ntjess]

Here's another use-case:

Consider a package that lists matplotlib as a dependency, but I never use the functions that rely on it. To cut down on my production size, I'd like to ignore matplotlib and everything that only matplotlib depends on.

Currently, #1509 would force me to mark every single subdependency of matplotlib as also unsafe (e.g. kiwisolver, cycling, pyparser, ... in this example) -- but only if they don't appear as dependencies of the packages I care about.

It also requires me to continually check whether matplotlib is adding new dependencies in new versions as I upgrade my pins.

Ideally, I can just --cut-deps matplotlib and not worry about it.

[webknjaz]

Looks like these use-cases are relying on the pip-compile output being used as pip requirement files. I've always seen them as rather pip constraints to be used as pip install -r deps.in -c constraints.txt (#2051).

Perhaps, for this use-case, a new output type/method is needed. Since the .in+.txt file pairs are kinda tightly coupled in their semantics. .txt is always expected to pin down the entire transitive tree of what's in .in.

UX-wise, I think it needs to be some setting for distinguishing what the input is (a regular list of direct deps vs. a patched one).

Perhaps, one day it could be paired with #2124.