Error on lockfiles with incoherent wheel versions #12235

konstin · 2025-03-17T10:10:16Z

Reject lockfiles where the package version and the wheel versions are incoherent. This implicitly checks that all wheel files have the same version.

It does not check for the source dist version, since a source dist may not contain a version in the filename and attempting to deserialize source dist filenames we may not need is a performance overhead for something that's already slow in uv run.

Fixes #12164
See also #12254

jtfmumm · 2025-03-17T10:20:12Z

crates/uv-resolver/src/lock/mod.rs

+                    }));
+                }
+            }
+            // We can't check the source dist version since it does not need to contain the version


We should always have at least one wheel enabling us to catch the inconsistency?

Not necessarily, for example:

dependencies = [ "sniffio", ] [tool.uv.sources] sniffio = { path = "sniffio.tar.gz" }

uv.lock:

[[package]] name = "sniffio" version = "1.3.1" source = { path = "sniffio.tar.gz" } sdist = { hash = "sha256:f4324edc670a0f49750a81b895f35c3adb843cca46f0530f79fc1babb23789dc" }

In this case, it's not possible to determine from the lockfile alone whether there is an inconsistency.

I've added another commit that catches all mismatches between locked source dist version and the built wheel versions at build time. This would enforce stricter guarantees than we require right now, CC @charliermarsh

As an example:

[[package]] name = "sniffio" version = "2.3.4" source = { url = "https://files.pythonhosted.org/packages/a2/87/a6771e1546d97e7e041b6ae58d80074f81b7d5121207425c964ddf5cfdbd/sniffio-1.3.1.tar.gz" } sdist = { hash = "sha256:f4324edc670a0f49750a81b895f35c3adb843cca46f0530f79fc1babb23789dc" }

With this last commit fails with:

× Failed to download and build `sniffio @ │ https://files.pythonhosted.org/packages/a2/87/a6771e1546d97e7e041b6ae58d80074f81b7d5121207425c964ddf5cfdbd/sniffio-1.3.1.tar.gz` ╰─▶ Package metadata version `1.3.1` does not match given version `2.3.4` help: `sniffio` was included because `foo` (v0.1.0) depends on `sniffio`

The potential clash could be with git dependencies that use a version-from-git integration.

Moved this to a separate PR: #12237

jtfmumm · 2025-03-17T10:25:51Z

crates/uv/tests/it/sync.rs

+      Caused by: Locked package and file versions are inconsistent for `iniconfig`
+    ");
+
+    // Without `--locked`, we could fail or recreate the lockfile, currently, we fail.


Would a user find this surprising? I think I'd assume uv will create a correct lockfile when running uv lock. And it might not be clear to a user what action they should take next if they see this error.

I guess it partially depends on what "If a lockfile is present, its contents will be used as preferences for the resolution" from the docs for uv lock means. Does that mean we try to use those preferences, but override them if necessary?

Currently, we fail on all kinds of parsing errors with lockfile. For example, an empty uv.lock fails:

$ uv lock error: Failed to parse `uv.lock` Caused by: TOML parse error at line 1, column 1 | 1 | | ^ missing field `version`

As does a lockfile where I removed the source line:

$ uv lock error: Failed to parse `uv.lock` Caused by: TOML parse error at line 16, column 1 | 16 | [[package]] | ^^^^^^^^^^^ missing field `source`

We can try to be better about recovering from a broken lockfile, but that's outside of the scope of the PR (uv would never write such a lockfile, and with this change, uv will refuse to sync a broken dependabot PR, failing CI). For comparison, in cases where the lockfile is not invalid but doesn't fully match in a non-version anymore, e.g., the environments changed, we for example only reuse the versions as preference but not the full lockfile (ValidatedLock enumerates the cases).

Reject lockfiles where the package version and the wheel versions are incoherent. This implicitly checks that all wheel files have the same version. It does not check for the source dist version, since a source dist may not contain a version in the filename and attempting to deserialize source dist filenames we may not need is a performance overhead for something that's already slow in `uv run`. Fixes #12164

charliermarsh · 2025-03-17T13:17:02Z

Does this mean that Dependabot updates will lead to hard uv errors? (I understand that, at least the linked issue, what they're doing today may not be sound.)

konstin · 2025-03-17T13:20:43Z

I think so, at least making PRs with this logic without updating source dist and wheels accordingly will lead to broken lockfiles: https://github.com/dependabot/dependabot-core/blob/1cd6fc59d7dae25d46255550528dd056c97c46d8/uv/lib/dependabot/uv/file_updater/lock_file_updater.rb#L111-L120. We currently accept those lockfile changes, but they don't do semantically what the PR diff would suggest (they don't actually upgrade the version).

Other commenters at dependabot/dependabot-core#10478 have noted that dependabot can produce lockfiles broken under --locked already (dependabot/dependabot-core#10478 (comment))

shauneccles · 2025-03-17T21:29:09Z

As a user and developer I want uv to explode if dependabot maims my lockfile so I know about it and so I can raise issues with dependabot.

urschrei · 2025-03-17T21:36:43Z

Other commenters at dependabot/dependabot-core#10478 have noted that dependabot can produce lockfiles broken under --locked already (dependabot/dependabot-core#10478 (comment))

Yep that's my lockfile, and they certainly do currently break them (tysm for --locked: it does what it says on the tin)

zanieb · 2025-03-17T21:38:29Z

crates/uv-resolver/src/lock/mod.rs

+                if version != &wheel.filename.version {
+                    return Err(LockError::from(LockErrorKind::InconsistentVersions {
+                        name: self.id.name,
+                    }));


Can we show the versions in the error here? Like "packaged version {} does not match {} from wheel {}"?

kleinhenz · 2025-03-18T13:19:30Z

This seems to have caused some problems with the flash-attn wheels.

#pyproject.toml
...

[tool.uv]
environments = ["sys_platform == 'darwin'", "sys_platform == 'linux'"]
constraint-dependencies = ["torch==2.5.1"]

[tool.uv.sources]
flash_attn = [
  { url = "https://github.com/Dao-AILab/flash-attention/releases/download/v2.7.3/flash_attn-2.7.3+cu12torch2.5cxx11abiFalse-cp310-cp310-linux_x86_64.whl", marker = "sys_platform == 'linux' and python_version == '3.10'"},
  { url = "https://github.com/Dao-AILab/flash-attention/releases/download/v2.7.3/flash_attn-2.7.3+cu12torch2.5cxx11abiFalse-cp311-cp311-linux_x86_64.whl", marker = "sys_platform == 'linux' and python_version == '3.11'"},
  { url = "https://github.com/Dao-AILab/flash-attention/releases/download/v2.7.3/flash_attn-2.7.3+cu12torch2.5cxx11abiFalse-cp312-cp312-linux_x86_64.whl", marker = "sys_platform == 'linux' and python_version == '3.12'"},
  { url = "https://github.com/Dao-AILab/flash-attention/releases/download/v2.7.3/flash_attn-2.7.3+cu12torch2.5cxx11abiFalse-cp313-cp313-linux_x86_64.whl", marker = "sys_platform == 'linux' and python_version == '3.13'"}
]

Now causes uv sync to error with

error: Failed to parse `uv.lock`
  Caused by: The entry for package `flash-attn` v2.7.3 has wheel `flash_attn-2.7.3+cu12torch2.5cxx11abifalse-cp310-cp310-linux_x86_64.whl` with inconsistent version: v2.7.3+cu12torch2.5cxx11abifalse

Not sure if there is a better way to configure usage of these wheels.

charliermarsh · 2025-03-18T13:21:00Z

Ah thanks, we can fix that.

`uv 0.6.6` adds a hard error when the version of the package in `uv.lock` does not match the one declared in the editable wheel: astral-sh/uv#12235. `release-please` doesn't update the lock files automatically, so release PRs needed a manual lock update. This PR adds the lockfile as an `extra-file`, to avoid this manual step. Note that the _jsonpath_ in the config is not technically correct, as release-please's json array filters don't quite work for toml files. See googleapis/release-please#2455, which includes this hacky workaround.

konstin added the bug Something isn't working label Mar 17, 2025

jtfmumm reviewed Mar 17, 2025

View reviewed changes

konstin force-pushed the konsti/locked-version-coherence branch from 36e4181 to eb6dcc0 Compare March 17, 2025 11:37

shauneccles mentioned this pull request Mar 17, 2025

Support updating uv.lock dependabot/dependabot-core#10478

Open

1 task

zanieb reviewed Mar 17, 2025

View reviewed changes

zanieb approved these changes Mar 17, 2025

View reviewed changes

zanieb requested a review from charliermarsh March 17, 2025 22:11

zanieb changed the title ~~Reject lockfiles with incoherent versions~~ Error on lockfiles with incoherent wheel versions Mar 17, 2025

zanieb merged commit 0c352c6 into main Mar 17, 2025
76 checks passed

zanieb deleted the konsti/locked-version-coherence branch March 17, 2025 22:33

zanieb mentioned this pull request Mar 17, 2025

Inconsistent version for wheel in lockfile updated by Dependabot #12254

Open

BrewTestBot mentioned this pull request Mar 18, 2025

uv 0.6.7 Homebrew/homebrew-core#211299

Merged

Gankra mentioned this pull request Mar 18, 2025

Validate locked versions against constraints in lock file #12276

Open

charliermarsh mentioned this pull request Mar 18, 2025

uv rejects flash-attn wheels with local versions #12282

Closed

aborgna-q mentioned this pull request Mar 18, 2025

ci: Update uv.lock on release-please PRs CQCL/guppylang#870

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Error on lockfiles with incoherent wheel versions #12235

Error on lockfiles with incoherent wheel versions #12235

konstin commented Mar 17, 2025 •

edited by zanieb

Loading

jtfmumm Mar 17, 2025

konstin Mar 17, 2025

konstin Mar 17, 2025

konstin Mar 17, 2025

konstin Mar 17, 2025

jtfmumm Mar 17, 2025

konstin Mar 17, 2025 •

edited

Loading

charliermarsh commented Mar 17, 2025

konstin commented Mar 17, 2025 •

edited

Loading

shauneccles commented Mar 17, 2025

urschrei commented Mar 17, 2025

zanieb Mar 17, 2025

zanieb Mar 17, 2025

kleinhenz commented Mar 18, 2025

charliermarsh commented Mar 18, 2025

Error on lockfiles with incoherent wheel versions #12235

Error on lockfiles with incoherent wheel versions #12235

Conversation

konstin commented Mar 17, 2025 • edited by zanieb Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

konstin Mar 17, 2025 • edited Loading

Choose a reason for hiding this comment

charliermarsh commented Mar 17, 2025

konstin commented Mar 17, 2025 • edited Loading

shauneccles commented Mar 17, 2025

urschrei commented Mar 17, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kleinhenz commented Mar 18, 2025

charliermarsh commented Mar 18, 2025

konstin commented Mar 17, 2025 •

edited by zanieb

Loading

konstin Mar 17, 2025 •

edited

Loading

konstin commented Mar 17, 2025 •

edited

Loading