-
Notifications
You must be signed in to change notification settings - Fork 983
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 lock
fails to update outdated lockfile if project is in cache
#10683
Comments
Can you include the verbose logging from |
Ahhh I see. This is basically a temporary effect of my PR to remove dynamic versions (#10622)... In short, we now reject your existing lockfile because it "looks like" the package has a static version in the lockfile but a dynamic version in practice. But in the cache, we're returning metadata that doesn't indicate a dynamic version (since the metadata is already cached and is missing that "dynamic" field). Arguably, I should've bumped the cache version there to avoid this. I need to think on whether that's worth doing. |
(I wouldn't expect this to be an ongoing problem.) |
when will it be sorted? ty! |
I imagine this would be resolved with |
@flipdazed -- I don't think this should be an ongoing problem? |
Maybe my problem is unrelated - it appeared in a runner out of nowhere though around the same time
because it's in a build stage of a docker image, I don't know if we can just clear it? |
I think you must be using two different versions of uv -- is that possible? It looks like the lockfile was generated by a more recent version than whatever your runner is using. |
Is this a sep issue? Shall I create a new thread? |
There isn't anything we can do about that, now that it's released. We arguably should've bumped the lockfile version or something similar, but we can't change the behavior for already-released uv versions. You need to bump the uv version in your runner. |
We have a base python image that does indeed have an older lock-file - we then run |
You need to avoid generating a lockfile on newer versions of uv, and then attempting to sync that lockfile on older versions of uv. So if you generated your lockfile with a newer version of uv than is what's on your base image, I suggest either (1) upgrading the base image or (2) downgrading your local version to match whatever is being used in the base image. |
Is there any workaround to basically hack this to get it running in the meantime like so?
|
I am still running into the "missing field
Failed run is here with raw logs here. I do see our GH Actions installing 0.5.20:
I removed cached files to make sure everything started fresh, just in case. Am I missing something? Thanks for your help. |
@moonbox3 -- I think you must be running an older uv version in pre-commit (which is versioned separately from whatever you install with GH Actions). |
We've just ran into an issue with uv on our repo coreax where uv was complaining the lockfile needed to be updated, but running
uv lock
did nothing.Reproduction (sorry, this isn't a minimal example, but it should work):
The diff here doesn't seem to be much of interest:
git diff uv.lock
However, if the project is not in the cache, we get a different result:
Inspecting the repo history, the offending
uv.lock
was generated using uv 0.5.18 (in this CI job, creating this commit).We were fortunately able to work around the issue using
uv lock --upgrade
with uv 0.5.20; it was only in creating a working example that I discovered the dependency on the cache.At a guess, this is maybe something to do with
coreax
's version being set dynamically inpyproject.toml
?The text was updated successfully, but these errors were encountered: