`--require-hashes` does not correctly handle pinned package with extras

What did you want to do?

Install this requirements.txt file with pip 21.0.1 or master in a new virtual environment.

A package is pinned to a non-latest version with an extra (here, requirements[security]) and another dependency requires this package without specifying the extra.

Output

Install fails with:

...
Collecting requests[security]==2.24.0
  Using cached requests-2.24.0-py2.py3-none-any.whl (61 kB)
Collecting six==1.15.0
  Using cached six-1.15.0-py2.py3-none-any.whl (10 kB)
Collecting urllib3==1.25.11
  Using cached urllib3-1.25.11-py2.py3-none-any.whl (127 kB)
Collecting requests<3
ERROR: In --require-hashes mode, all requirements must have their versions pinned with ==. These do not:
    requests<3 from https://files.pythonhosted.org/packages/29/c1/24814557f1d22c56d50280771a17307e6bf87b70727d975fd6b2ce6b014a/requests-2.25.1-py2.py3-none-any.whl#sha256=c210084e36a42ae6b9219e00e48287def368a26d03a048ddad7bfee44f75871e (from requests-extra==1.0.0b3->-r requirements.txt (line 116))

The resolver does not recognise that requests[security]==2.24.0 fulfils requests<3, and tries to collect latest requests. This fails as it is has no pinned hash.

Additional information

Installation succeeds with --use-deprecated=legacy-resolver.

If the requirements file has no hashes, installation succeeds with the new resolver: Collecting requests<3 resolves to latest requests (2.25.1) in the install output, but the pinned version (2.24.0) is what ends up installed.

If all packages are already installed in the environment, pip install succeeds (with Requirement already satisfied) even with the new resolver.

[maljub01]

One workaround for this is to use --no-deps, which is a good idea by itself anyway (See the second warning here).

[di]

That still passes, but after looking more closely I was able to figure out what will cause it to fail:

• two parent dependencies
  • one with a dependency on a child with an extra
  • one with a dependency on a child without an extra
• a newer version of the child dependency available than is pinned

It seems like what’s happening is that pip is not considering the child dependency with the extra to be equivalent to the child dependency without the extra, and attempting to install the latest version of the child dependency, and not using the existing pinned/hashed requirement when doing this, which causes the hash checking to fail.

I made a draft PR with the failing test here: https://github.com/pypa/pip/pull/9995, but I don’t have time at the moment to continue working on it to fix the issue.