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.