pip-tools icon indicating copy to clipboard operation
pip-tools copied to clipboard

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

Open cjerdonek opened this issue 3 years ago • 7 comments

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 avatar Feb 23 '21 12:02 cjerdonek

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.)

cjerdonek avatar Feb 23 '21 23:02 cjerdonek

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.

plannigan avatar May 16 '21 20:05 plannigan

Hello @cjerdonek,

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

atugushev avatar Oct 12 '21 18:10 atugushev

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.

mortbauer avatar Feb 27 '23 11:02 mortbauer

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?

juledwar avatar Nov 02 '23 04:11 juledwar

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

lalten avatar Jan 31 '24 22:01 lalten

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.

plannigan avatar Feb 04 '24 00:02 plannigan