-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hash checking mode fails if a package publishes a late built distribution #11692
Comments
For the record, using |
There ia already #5874 so apparently something broke. |
Ah, bad03ef implemented hash-population incorrectly, so Links fetched from JSON are missing hashes. Edit: On further inspection, the error is not in that commit, but much earlier, likely when we introduced JSON support. |
Does #11538 fix this? |
Just installed
|
Description
E.g. see https://gitlab.com/doctormo/python-crontab/-/issues/103
python-crontab 2.6.0 was released on Oct 19th, 2021 but only a source .tar.gz distribution. On Dec 20th, 2022 a built .whl distribution was pushed for the same 2.6.0 version. Because the wheel is not discarded, installation fails.
So, for a wide timespan, the tarball hash was legitimately the only whitelisted hash for a bunch of people expecting reproducible installs.
While the case for python-crontab 2.6.0 is a bit extreme, being a lockfile-watching weirdo like me reveals the scenario is repeatedly happening because of ecosystem's adoption of new platform tags like musllinux and recent CPython versions.
Follow-up from pypa/pipenv#5550
Expected behavior
Discard the wheel and install the tarball that matches the hash. Generally speaking, discard any artifact not matching some of the hashes before choosing among them.
It turns out pip==22.2.2 handled this just fine!
pip version
22.3+
Python version
3.10.8
OS
linux
How to Reproduce
Given the following requirements.txt
Run
Output
but for the previous pip==22.2.2
Code of Conduct
The text was updated successfully, but these errors were encountered: