Hash mismatch when fetching 1.19.0

[danielhoherd]

Hash mismatch when fetching 1.19.0

[uranusjr]

I hand-downloaded and checked, the artifact on PyPI matches the hash. This may be a network issue in the CI environment that corrupts the download.

[wimglenn]

There must be some bug in pip, pip-tools, or pipenv.
9ff82852bcb65d139813e2a5197627a94966245c897796760a3a2a8eb66f020b is the correct sha256 for parse-1.19.0.tar.gz
6ce007645384a91150cb7cd7c8a9db2559e273c2e2542b508cd1e342508c2601 is the correct sha256 for parse-1.19.0-py2.py3-none-any.whl
The tooling should not be comparing the hash of an sdist with the hash of a wheel.

@uranusjr I doubt it is a network issue - someone else saw the same thing in #156
Are you familiar with the code in https://github.com/pypa/pip/blob/main/src/pip/_internal/utils/hashes.py ? How would it handle this case:

1. A project creates/uploads a release with only an sdist
2. Then, someone creates their requirements.txt file with hashes
3. Sometime later the project from 1. puts a whl to PyPI with the same version number as the sdist (which will be preferred by pip)

When it's doing hash checking, does pip understand that there are two files for parse==1.19.0 and it's normal for them to have different hashes? How does it distinguish between parse==1.19.0 being satisfied by wheel vs by sdist in a requirements file? Could it check all files satisfying the requirement and then just choose the one with matching hash, rather than always try to grab the wheel?

Related: pypa/pipenv#3893

[wimglenn]

Closing because there's nothing actionable for parse here.