Error or warn when uv.lock version is unsupported
#8465
Assignees
Labels
error messages
Messaging when something goes wrong
Comments
charliermarsh
added a commit
that referenced
this issue
Oct 23, 2024
…8501) ## Summary Per discussion on Discord, we're going to keep these names for now (changed in #8391 but not yet released) for compatibility. They're just cosmetic, but with the changes as-is, if you ran an older uv version over a newer lockfile... - For `uv sync`: the lockfile would be invalidated, and we'd re-resolve. - For `uv sync --frozen`: we'd silently skip the development dependencies. We'll change these names in the future once we've added better error handling around lockfile versions (#8465).
charliermarsh
added a commit
that referenced
this issue
Oct 24, 2024
## Summary Historically, we haven't enforced schema versions. This PR adds a versioning policy such that, if a uv version writes schema v2, then... - It will always reject lockfiles with schema v3 or later. - It _may_ reject lockfiles with schema v1, but can also choose to read them, if possible. (For example, the change we proposed to rename `dev-dependencies` to `dependency-groups` would've been backwards-compatible: newer versions of uv could still read lockfiles that used the `dev-dependencies` field name, but older versions should reject lockfiles that use the `dependency-groups` field name.) Closes #8465.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now, I don't think we validate this anywhere.
The text was updated successfully, but these errors were encountered: