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

uv-cache: bump built-wheels cache version #2715

Merged
merged 1 commit into from
Mar 28, 2024
Merged

Conversation

BurntSushi
Copy link
Member

It turns out that #2712 did not fix #2711. After I put up #2712, I
started trying to track down the specific change that caused the
failure. I had assumed at first that it was related to one of our rkyv
types, but it actually ended up being one of our msgpack caches. I think
the failure mode is still fundamentally the same idea: the cached data
changed in a way that is still valid msgpack, but got interpreted
differently after deserializing.

The specific change that caused this was the removal of a field from our
metadata type.

Ideally we would just undo the change and add the field back. But that
change has already been shipped out to users. So I believe the only
plausible choice at this point is to bump the built-wheels cache. This
will unfortunately mean that uv will need to re-build wheels.

Fixes #2711

It turns out that #2712 did _not_ fix #2711. After I put up #2712, I
started trying to track down the specific change that caused the
failure. I had assumed at first that it was related to one of our `rkyv`
types, but it actually ended up being one of our msgpack caches. I think
the failure mode is still fundamentally the same idea: the cached data
changed in a way that is still valid msgpack, but got interpreted
differently after deserializing.

The specific change that caused this was the [removal of a field] from our
metadata type.

Ideally we would just undo the change and add the field back. But that
change has already been shipped out to users. So I believe the only
plausible choice at this point is to bump the `built-wheels` cache. This
will unfortunately mean that `uv` will need to re-build wheels.

Fixes #2711

[removal of a field]: 365c292#diff-e42586829f9c2cdbb909bedc5cf95691cc415247f2cbc2ebeb80d887020457bbL29
@BurntSushi
Copy link
Member Author

Here is my test protocol. First, the failure:

$ rm -rf ~/.cache/uv && rm -rf .venv && uv-0.1.24 venv && uv-0.1.24 pip install -q homeassistant
Using Python 3.12.0 interpreter at: /home/andrew/.pyenv/versions/3.12.0/bin/python3
Creating virtualenv at: .venv
Activate with: source .venv/bin/activate
$ uv-0.1.25 pip install -q homeassistant --reinstall-package homeassistant
error: Failed to download and build: pyric==0.1.6.3
  Caused by: Failed to deserialize cache entry
  Caused by: expected version to start with a number, but no leading ASCII digits were found
$

And now a demonstration that this PR doesn't have the issue:

$ rm -rf ~/.cache/uv && rm -rf .venv && uv-0.1.24 venv && uv-0.1.24 pip install -q homeassistant
Using Python 3.12.0 interpreter at: /home/andrew/.pyenv/versions/3.12.0/bin/python3
Creating virtualenv at: .venv
Activate with: source .venv/bin/activate
$ uv-this-pr pip install -q homeassistant --reinstall-package homeassistant
$

@charliermarsh
Copy link
Member

You should also be able to un-bump the simple cache version.

@charliermarsh
Copy link
Member

But... I don't feel strongly. Let's just leave it bumped actually.

@zanieb zanieb merged commit 7b685a8 into main Mar 28, 2024
31 checks passed
@zanieb zanieb deleted the ag/bump-built-wheel-cache branch March 28, 2024 18:24
@BurntSushi
Copy link
Member Author

Yeah I thought about that, but didn't want to get too cute since that bump already landed on main.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Cache issues when upgrading to 0.1.25
3 participants