Support '--unstable-feature' in requirements files

[rouge8]

This patch adds support for --unstable-feature in requirements files so that a project that wants all contributers using the same pip features can specify it in the requirements file. For example, to ensure a requirements file uses the new resolver:

--unstable-feature=resolver
boto3
boto3==1.13.13

[pfmoore]

First of all, thanks for testing the new resolver, and for helping out by submitting this PR!

However, I'm not sure I consider it a good idea to support this. It feels to me like it's promoting unstable features (note: the flag is intended as a general mechanism, not just for the resolver) to something that should be "switched on" and then forgotten about, rather than something that should only be used deliberately, for testing the new feature. We already have "global" mechanisms for enabling the new resolver (environment variables and the config file), for cases like automation, if needed.

Also, those requirements files would be broken when the new resolver gets rolled out, and stops being "unstable" (and there may even be a stage where the new resolver is stable, but off by default, at which point we'd have a different flag to be set...)

@pradyunsg @uranusjr what are your views?

[rouge8]

It feels to me like it's promoting unstable features (note: the flag is intended as a general mechanism, not just for the resolver) to something that should be "switched on" and then forgotten about

Yeah, I guess that's my goal with this PR. We're currently stuck on pip 18.1 because of #5780, which is fixed in the new resolver. Environment variables are fine for CI and automation and etc, but putting it in requirements.txt would let us upgrade to 20.2 when it comes out and everybody would keep using the pip install -r requirements.txt workflow they've used forever. Maybe that's too niche though!

[uranusjr]

The problem I have is that the --unstable-feature flag itself is also unstable. Once we stablise the new resolver, all requirements files specifying --unstable-feature=resolver will break (because resolver is no longer a valid value). I’m -0 on adding this since the consequence feels wrong to me.

[pfmoore]

Apart from niche, I'd be strongly against anyone running the new resolver in a production system at this point.

Having read the background, I get why you'd want to switch over as soon as possible. I can certainly see a valid reason for supporting the "official" use-new-resolver switch in a requirements file, but I think we should hold off on doing it for --unstable-feature.

[pradyunsg]

I'm a strong -1 on this.

Thanks @rouge8! While I understand why you'd like this, it's likely that we'd add something like a --resolver=legacy/new flag for use cases like yours.

The --unstable-feature flag is meant for more general use within pip, for more than just the resolver rollout, and I'd prefer we avoid making it accessible from requirements file.