Prompt user to use the backtracking resolver on errors

[maxfenv]

Prompt the user to use the backtracking resolver if the legacy resolver is in use and pip-tools is failing to resolve the dependencies. This is as mentioned in #1717 and related to PR #1718.

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).

[maxfenv]

Looks like I'm missing a couple of tests here to get good enough coverage. I'll work on that a little, but it might take me a small while to figure out how to do that.

[atugushev]

Looks like I'm missing a couple of tests here to get good enough coverage. I'll work on that a little, but it might take me a small while to figure out how to do that.

Let me help you with a mininal test.

Setup the following dummy packages and prepare wheels on dists dir

• a==0.1 depends on b==0.1
• a==0.2 depends on b==0.2
• c depends on a and b==0.1

Create requirements.in file

c

Legacy

$ pip-compile --pip-args="--no-index" --find-links dists --no-header
Could not find a version that matches b==0.1,==0.2 (from c==0.1->-r requirements.in (line 1))
Tried: 0.1, 0.2
There are incompatible versions in the resolved dependencies:
  b==0.1 (from c==0.1->-r requirements.in (line 1))
  b==0.2 (from a==0.2->c==0.1->-r requirements.in (line 1))

Backtracking

$ pip-compile --pip-args="--no-index" --find-links dists --no-header --resolver backtracking
--find-links dists

a==0.1
    # via c
b==0.1
    # via
    #   a
    #   c
c==0.1
    # via -r requirements.in

Use this test as example how to make package and wheels.

[maxfenv]

Thanks for the hints!

[maxfenv]

Not sure what to do about the macos test failure. It's a failure in an unrelated test (I think?) so it's probably safe to ignore in this context.

Not sure what's happening with the lack of test coverage though. Tox reports the same locally too. This test https://github.com/jazzband/pip-tools/pull/1719/files#diff-99b06d953a9978ee564df2e67547b8a76f3b1ab116ab7c89a9005b9239f2a904R2492 should certainly be hitting the new code. It passes when run in isolation:

tox -e py310 -- tests/test_cli_compile.py::test_success_of_legacy_resolver_doesnt_prompt_for_backtracking

And there is no indication that it's failing here either. Is it just not running during the coverage check or something?

[atugushev]

Not sure what to do about the macos test failure. It's a failure in an unrelated test (I think?) so it's probably safe to ignore in this context.

It's unrelated to your PR. See #1720 for details.

[atugushev]

LGTM. Thanks a lot! 🎉

[maxfenv]

Thanks very much for your hand holding with this!