-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Feature Request: Remove Unused Generated Hashes #3516
Comments
Is this roughly the same as #3334? |
I think this is a very reasonable request but we need some new API for it. Something like: |
@charliermarsh Yes, with one difference. It seems the other poster is requesting an opt-in flag for generate hashes to do this behavior. My thoughts are this behavior should become the only option. Pure python packages would be unaffected. And while that would be backwards incompatible for packages with binaries per platform, those relying on the current behavior are carrying a risk anyways because they are performing development / testing with a binary different than production. That discrepancy could result in buggy behavior like in example of original post. |
Ah we commented at same time. Yes, the example API you gave would still be wonderful for my usecase and would enable smooth transition for existing users. In case you wanted to consider how an API could look for the more strict change I recommended above, I'd suggest a Only one requirement compilation needed for same environment across board, two requirement compilations needed for iterating and deploying to different environment. If someone with the latter usecase used the proposed |
Actually, my suggestion of having to separately generate a lock file for the production environment only would require #3347. At that point, I believe my suggested |
From the README:
When
--generate-hashes
is supplied, since there is the above restriction on using requirements.txt anyways, is it possible to output only the hash(es) for that platform and Python version?I know that uv behaves like pip-compile here. The main appeal of my suggestion is reducing the amount of volume being checked into the repository (see spoiler for how much was generated from one dependency). I imagine there would also be a slight uv pip compile, install and sync performance boost for not having to calculate and check against as many hashes.
Additionally, I think it would also improve reproducible slightly, though please correct me if any of my following logic is wrong. Say my application is working on Python 3.12 Windows given my compiled requirements on that developer platform and version combination. Perhaps the libraries I am using require extra dependencies when running on older Python versions (like
typing_extensions
to stub for new additions intyping
) and a different OS. I then accidentally install my compiled requirements on and start my app in a Python 3.11 Linux environment where my service isn't going to work due to those needed extra dependencies missing.Under the proposed behavior, I would find out about the host mismatch at build time, by my uv pip sync / install failing due to a hash for a different platform plus version not being listed. Under the current behavior, the install on the mismatched environment would still succeed and I would find out at runtime when one of my dependencies throws an error about say
typing_extensions
missing.I think finding out about that mismatch at build time vs. at run time is universally preferable.
90 Hashes for One Dependency
The text was updated successfully, but these errors were encountered: