Resolving package with duplicate dependencies results in incorrect constraint

[RealOrangeOne]

When trying to resolve a package which depends on its dependency twice, but with different constraints (Eg as a core dependency and in an extra), it's possible for the resulting constraint to not be valid, as if the extra dependency had been ignored.

I can reliably replicate this with a specific package: django-stubs[compatible-mypy].

From some debugging, it appears that the first round of resolving correctly picks up the initial constraint of mypy>=0.930, however the extra actually defines the constraint with an upper bound (mypy>=0.930,<0.970). This extra constraint doesn't appear to ever be considered during resolution.

Environment Versions

1. OS Type
2. Python version: $ python -V 3.10
3. pip version: $ pip --version 22.2.0
4. pip-tools version: $ pip-compile --version 6.8.0

Steps to replicate

1. Create a requirements file which depends on django-stubs[compatible-mypy]
2. pip-compile

Expected result

mypy is pinned to 0.961 - the latest version to match the constraints

Actual result

mypy is pinned to 0.971, which during a pip install results in a failure:

ERROR: Cannot install django-stubs[compatible-mypy]==1.12.0 and mypy==0.971 because these package versions have conflicting dependencies.
 
 The conflict is caused by:
     The user requested mypy==0.971
     django-stubs[compatible-mypy] 1.12.0 depends on mypy>=0.930
     django-stubs[compatible-mypy] 1.12.0 depends on mypy<0.970 and >=0.930; extra == "compatible-mypy"

[atugushev]

Have you tried pip-compile --resolver backtracking? Legacy resolver isn't perfect and going to be deprecated soon.

[RealOrangeOne]

The backtracking resolver does indeed pick up the correct version (mypy==0.961).

My short term solution was to modify the requirements file manually to fix the constraint, as 0.961 still satisfies, but obviously would be nice for that not to have been necessary!

[atugushev]

Switching to the backtracking resolver is highly encouraged since there are no further plans to support the legacy resolver. Thanks for the issue anyway!

[RealOrangeOne]

Thanks, i'll update my projects to the new resolver. Look forward to it becoming the default with #1659