pip-tools
pip-tools copied to clipboard
Provide a way to limit to a single hash per requirement when generating hashes
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).
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.)
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.
Hello @cjerdonek,
Could you try out the #1406? Does it resolve the issue?
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.
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?
bump on this, would be awesome if you could take another stab at it @plannigan ?
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.