-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
BUG: Reading from cache archive failed
while upgrading pytest
#1571
Comments
Will look into this (\cc @BurntSushi), but in the meantime, you can do |
(Thank you for the clear issue!) |
Thanks for the crazy fast response! This did indeed work for me, thanks! |
(I just opened #1609, which is possibly a duplicate of this issue) |
Cross-posting: I believe I've confirmed locally that this was caused by #1556. I changed one of the cached structs, and that breaks the zero-copy representation. I should've bumped the cache version. |
It might be worth adding test coverage for these kinds of bumps, or some other form of testing and enforcement. (\cc @BurntSushi just for visibility.) |
This PR introduces more robust cache healing when `uv` fails to deserialize an existing cache entry. ("Cache healing" in this context means that if `uv` fails to deserialize a cache entry, then it will automatically invalidate that entry and re-generate the data. Typically by sending an HTTP request.) Previous to some optimizations I made around deserialization, we were already doing this. After those optimizations, deserializing a cache policy and the payload were split into two steps. While deserializing a cache policy retained its cache healing behavior, deserializing the payload did not. This became an issue when #1556 landed, which changed one of our `rkyv` data types. This in turn made our internal types incompatible with existing cache entries. One could work-around this by clearing `uv`'s cache with `uv clean`, but we should just do it automatically on a cache entry by entry basis. This does technically introduce a new cost by pessimistically cloning the HTTP request so that we can re-send it if necessary (see the commit messages for the knot pushing me toward this approach). So I re-ran my favorite ad-hoc benchmark: ``` $ hyperfine -w10 --runs 50 "uv-main pip compile --cache-dir ~/astral/tmp/cache-main ~/astral/tmp/reqs/home-assistant-reduced.in -o /dev/null" "uv-test pip compile --cache-dir ~/astral/tmp/cache-test ~/astral/tmp/reqs/home-assistant-reduced.in -o /dev/null" ; A bart Benchmark 1: uv-main pip compile --cache-dir ~/astral/tmp/cache-main ~/astral/tmp/reqs/home-assistant-reduced.in -o /dev/null Time (mean ± σ): 114.4 ms ± 3.2 ms [User: 149.4 ms, System: 221.5 ms] Range (min … max): 106.7 ms … 122.0 ms 50 runs Benchmark 2: uv-test pip compile --cache-dir ~/astral/tmp/cache-test ~/astral/tmp/reqs/home-assistant-reduced.in -o /dev/null Time (mean ± σ): 114.0 ms ± 3.0 ms [User: 146.0 ms, System: 223.3 ms] Range (min … max): 105.3 ms … 121.4 ms 50 runs Summary uv-test pip compile --cache-dir ~/astral/tmp/cache-test ~/astral/tmp/reqs/home-assistant-reduced.in -o /dev/null ran 1.00 ± 0.04 times faster than uv-main pip compile --cache-dir ~/astral/tmp/cache-main ~/astral/tmp/reqs/home-assistant-reduced.in -o /dev/null ``` Which is about what I expected. We should endeavor to have a better testing strategy for these kinds of bugs, but I think it might be a little tricky to do. I created #1699 to track that. Fixes #1571
Hi! Thanks for making uv! I just upgraded to
uv
0.1.3 from 0.1.2 and wanted to upgrade pytest (from 8.0.0 to 8.0.1), so I ranuv pip install -U pytest
, however that resulted in an error:Here's the full error with
--verbose
:Log
Other packages like
typing-extensions
seem to upgrade just fine, only pytest is causing this issue. Also reproducible on uv 0.1.2.uv version: 0.1.3
Build: Ubuntu 23.10, Linux kernel 6.5.0 x86_64
Python: 3.12.2
Rust: 1.76.0
The text was updated successfully, but these errors were encountered: