After upgrading to pip 22.3, package fails hash check

[matt-carr]

Description

the following requirements file fails to install

#                                                                                                   
# Default dependencies
#
py-healthcheck==1.10.1 \
    --hash=sha256:60bbaab729a89098f0e6723ba5b6ab4ca8bde79b1a1bdb324f2b9e39df33780d

with the following error

➤ pip install --no-cache-dir -r dev-requirements.txt
Collecting py-healthcheck==1.10.1
  Downloading py_healthcheck-1.10.1-py3-none-any.whl (9.3 kB)
ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
    py-healthcheck==1.10.1 from https://files.pythonhosted.org/packages/cc/6f/4866a0d4739b052ffbdaca540df2ba1023504937a57808a6c71158e6fef4/py_healthcheck-1.10.1-py3-none-any.whl (from -r dev-requirements.txt (line 4)):
        Expected sha256 60bbaab729a89098f0e6723ba5b6ab4ca8bde79b1a1bdb324f2b9e39df33780d
             Got        2c340026acda509073667476e1bd45b66d7c8d345cd6aa8f91b156edd7bd4e02

The install proceeds as expected with pip 22.2.2 and the expected SHA matches the sha on pypi

Expected behavior

The package is installed as expected

pip version

22.3

Python version

3.9.15

OS

WSL2, whatever's running in Github Actions

How to Reproduce

1. install pip 22.3
2. pip install --no-cache-dir -r requirements.txt where requirements.txt contains the aforementioned content

Output

Collecting py-healthcheck==1.10.1
  Downloading py_healthcheck-1.10.1-py3-none-any.whl (9.3 kB)
ERROR: THESE PACKAGES DO NOT MATCH THE HASHES FROM THE REQUIREMENTS FILE. If you have updated the package versions, please update the hashes. Otherwise, examine the package contents carefully; someone may have tampered with them.
    py-healthcheck==1.10.1 from https://files.pythonhosted.org/packages/cc/6f/4866a0d4739b052ffbdaca540df2ba1023504937a57808a6c71158e6fef4/py_healthcheck-1.10.1-py3-none-any.whl (from -r dev-requirements.txt (line 4)):
        Expected sha256 60bbaab729a89098f0e6723ba5b6ab4ca8bde79b1a1bdb324f2b9e39df33780d
             Got        2c340026acda509073667476e1bd45b66d7c8d345cd6aa8f91b156edd7bd4e02

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[uranusjr]

The hash you provided is for the source distribution, while the hash you got is for the wheel. So it seems to indicate something’s wrong with the hash filtering logic (IIRC pip should try both and download the one with matching hash).

What happens if you add --no-binary=py-healthcheck to the command? (This would explicitly make pip choose the sdist.)

[matteius]

@uranusjr We have run into a similar issue with pipenv after upgrading to 22.3. I thought that design of pip has it prefer to find package in pypi by default, and in this example report pypa/pipenv#5444 we find that the command that is issued:

Preparing Installation of 'asgiref'
$ /home/matteius/.virtualenvs/pipenv-issue-repro-NBOIBieE/bin/python /home/matteius/pipenv/pipenv/patched/pip/__pip-runner__.py install -i https://pypi.python.org/simple --extra-index-url https://www.piwheels.org/simple --no-input --upgrade --no-use-pep517 --no-deps --exists-action=i -r /tmp/pipenv-dzv0lewb-requirements/pipenv-oskslra1-hashed-reqs.txt

This shows the primary index being passed is still https://pypi.python.org/simple and the extra index is https://www.piwheels.org/simple -- yet someone when the install phase happens its pulling the package from piwheels.org and failing the hash check (which had resolved hashes from pypi) and somehow the hashes are different between piwheels.org and pypi.

Also from reading your prior comment, I will try adding --no-binary=py-healthcheck to the install command to see if it behaves differently.

Edit: adding --no-binary=py-healthcheck seemed to have no effect reported to pipenv.

[uranusjr]

I don’t think index selection is the cause here; in the original post, both files are from the same index (PyPI).

[sbidoul]

Could this have the same cause as #11527?

[matt-carr]

The hash you provided is for the source distribution, while the hash you got is for the wheel. So it seems to indicate something’s wrong with the hash filtering logic (IIRC pip should try both and download the one with matching hash).

What happens if you add --no-binary=py-healthcheck to the command? (This would explicitly make pip choose the sdist.)

This worked, but additionally added the following deprecation warning (which I assume is expected):

  DEPRECATION: py-healthcheck is being installed using the legacy 'setup.py install' method, because the '--no-binary' option was enabled for it and this currently disables local wheel building for projects that don't have a 'pyproject.toml' file. pip 23.1 will enforce this behaviour change. A possible replacement is to enable the '--use-pep517' option. Discussion can be found at https://github.com/pypa/pip/issues/11451

[sbidoul]

I could reproduce this, and I confirm that #11538 restores the pre 22.3 behaviour.