Skip to content
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

Provide a way to limit to a single hash per requirement when generating hashes #1330

Open
cjerdonek opened this issue Feb 23, 2021 · 7 comments
Labels
feature Request for a new feature hashes Related to hashes generated via --generate-hashes

Comments

@cjerdonek
Copy link

cjerdonek commented Feb 23, 2021

What's the problem this feature will solve?

Currently, when the --generate-hashes option is passed to pip-compile, pip-compile will include potentially many hashes per requirement, even if only one is needed / desired.

Describe the solution you'd like

This feature request is for pip-compile to expose a command-line option that would limit the output to including only a single hash, namely the hash of what would be installed in the environment in which pip-compile is being run.

This option would be useful in situations where the exact deployment target is known (e.g. when using containers). For one, the requirements files generated by pip-compile would be shorter and easier to review since they wouldn't include extraneous info. Secondly, I believe this would provide greater determinism / reproducibility. For example, currently, if a release that was previously being installed from a requirements file generated by pip-compile was yanked from PyPI, then the result of what would be installed from that requirements file could change, even though the requirements file didn't change (because the requirements file currently includes more hashes than what was originally installed).

@cjerdonek
Copy link
Author

Maybe this could be implemented with an option that accepts a value, e.g. --generate-hashes exact vs. all (the current default). (I don't know off-hand if this approach could be done in a backwards-compatible fashion with the existing option.)

@atugushev atugushev added feature Request for a new feature hashes Related to hashes generated via --generate-hashes labels Feb 24, 2021
@plannigan
Copy link
Contributor

I was looking into this a bit. It looks like packaging.utils.parse_wheel_filename() would allow for getting the tags for each file that is available on PyPI. That can be compared with the executing python version. However, some packages upload multiple manylinux variants for the same version, so there would need to be additional logic to select the preferred file (must exist somewhere in pip, but I haven't dug deep enough yet).

In the case of needing to actually download the files to get the hash, removing the call to allow_all_wheels() causes find_all_candidates() to only produce candidates that are compatible with the executing python version. Again, the preferred file logic would be needed to filter down the candidates to what pip would actually install.

@atugushev
Copy link
Member

Hello @cjerdonek,

Could you try out the #1406? Does it resolve the issue?

@mortbauer
Copy link

Seems #1406 was closed since it was outdated, but seems a solution was already implemented there, would need somebody to take it up again it seems.

@juledwar
Copy link

juledwar commented Nov 2, 2023

This is quite a problem for my environment; some packages produce around 30-40 hashes and it takes over half an hour for my requirements to generate. Is anyone still working on a fix?

@lalten
Copy link

lalten commented Jan 31, 2024

bump on this, would be awesome if you could take another stab at it @plannigan ?

@plannigan
Copy link
Contributor

I don't think this is something I'm likely to return to. If anyone want to work on this issue, feel free to use my previous work as a jumping off point.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature Request for a new feature hashes Related to hashes generated via --generate-hashes
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants