Pip: Implement step 1 in resolver rollout process

[nlhkabu]

As per https://github.com/pypa/pip/issues/8371#issuecomment-652422199:

We need to:

• Add a warning on pip install X for users who are likely to experience problems with the new resolver
• Allow users to turn on the new resolver with --use-feature=2020-resolver
• Remove --unstable-feature=resolver
• Raise an error when a user uses --unstable-feature=resolver - pointing the users to use --use-feature=2020-resolver instead.

UX TODO: @ei8fdb and I can provide the text for the error and warning messages.

[pradyunsg]

• Allow users to turn on the new resolver with --use-feature=2020-resolver
• Raise an error when a user uses --unstable-feature=resolver - pointing the users to use --use-feature=2020-resolver instead.

8530 implements this.

• Remove --unstable-feature=resolver

To me, this means stop handling (and accepting) that like any other command line option. In other words, it would look something like:

$ pip install --random-non-existent-option=whatever

Usage:   
  pip install [options] <requirement specifier> [package-index-options] ...
  pip install [options] -r <requirements file> [package-index-options] ...
  pip install [options] [-e] <vcs project url> ...
  pip install [options] [-e] <local project path> ...
  pip install [options] <archive url/path> ...

no such option: --random-non-existent-option

These seem a bit... contradictory to the last bullet's intent, so I've gone ahead and implemented specific handling for --unstable-feature, to print the helpful error message. It'll be easy enough to remove the less-than-25 lines of code to drop --unstable-feature in pip 20.3.

@nlhkabu @ei8fdb Lemme know if that sounds OK. :)

[pradyunsg]

• Add a warning on pip install X for users who are likely to experience problems with the new resolver

I'm going to break this out into a separate PR(s?). I take "problems" to mean "change in behavior". As with any change, we can't have a 100% true-positive coverage but I think we can get pretty close with minimal false-negatives.

@pfmoore @uranusjr Need a bit of help here... As far as I can tell, the main areas where the two resolvers' behavior will differ are:

• when there's a conflict in the dependency graph
• handling of constraints

Am I missing something, or are these the only "broad" areas where the behavior differs?

[pfmoore]

Those are the two I can think of. I'll try to review over the weekend - but this week's been really busy so I have a lot to catch up on, so I'd say add those two and we can always add extra ones as and when we spot them.

[nlhkabu]

@pradyunsg please let me know once those PRs are in progress and we can help you with the warning text for each use case

[pradyunsg]

@nlhkabu there's 2 PRs and 1 issue cross-linked to this issue.

Each PR is adding an error message that could use a review (I merged them eagerly since it's easy enough to iterate in a follow up PR).

The linked open issue is where I'd need inputs, specifically around what the exact messages should be in the situations outlined there.

[nlhkabu]

ok thanks @pradyunsg - just read #8546 and realised that's where you want our input :)

[stonebig]

on an existing install made without the new resolver, is there a simple way to check the new resolver is happy ?
does this do the trick ?
pip check --unstable-feature=resolver

[uranusjr]

A simple pip check would suffice, no need to add any flags.

[brainwane]

The only thing left for this is updating the error message. This gets closed along with #8546.