uv: resolution errors from uv >= 0.12.14 are no longer recognised (× No solution found regexes) #16510

Is there an existing issue for this?

• I have searched the existing issues

Package ecosystem

uv

Package manager version

uv 0.12.18 (Dependabot's bundled uv)

Language version

Python 3.14.7 (the default interpreter in the uv development image)

Manifest location and content before the Dependabot update

/pyproject.toml and /uv.lock, with a pair of packages that pin each other exactly:

[project]
name = "demo"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
    "opentelemetry-api==1.25.0",
    "opentelemetry-sdk==1.25.0",
]

dependabot.yml content

version: 2
updates:
  - package-ecosystem: "uv"
    directory: "/"
    schedule:
      interval: "daily"

Updated dependency

opentelemetry-api 1.25.0 → 1.26.0

What you expected to see, versus what you actually saw

Since uv 0.12.14, uv reports resolution failures as error: / cause: instead of × / ╰─▶. Dependabot picked this up in #16276, which moved the bundled uv from 0.12.7 to 0.12.15. With api bumped to 1.26.0, uv 0.12.18 prints:

Using CPython 3.14.7 interpreter at: /usr/local/.pyenv/versions/3.14.7/bin/python3
error: No solution found when resolving dependencies
  cause: Because opentelemetry-sdk==1.25.0 depends on opentelemetry-api==1.25.0 and your project depends on opentelemetry-api==1.26.0, we can conclude that your project and opentelemetry-sdk==1.25.0 are incompatible.
         And because your project depends on opentelemetry-sdk==1.25.0, we can conclude that your project's requirements are unsatisfiable.

The uv ecosystem still looks for the old format: UV_UNRESOLVABLE_REGEX and UV_BUILD_FAILED_REGEX in LockFileErrorHandler, and the separate UV_UNRESOLVABLE_REGEX in PipCompileVersionResolver, all require ×. uv 0.12.13 and earlier still print the × form, so both formats need to keep working.

Expected: what happened before #16276, with the bundled uv 0.12.7. LockFileErrorHandler finds the conflict sentence and raises UpdateNotPossible for opentelemetry-sdk and opentelemetry-api, and LockFileResolver#resolvable? treats the conflict as "not resolvable" and returns false.

Actual: the regex doesn't match, so LockFileUpdater raises DependencyFileNotResolvable with uv's raw output, Using CPython … line included. The conflict extraction never runs, so UpdateNotPossible is never raised. LockFileResolver#resolvable?(version: 1.26.0) re-raises that DependencyFileNotResolvable instead of returning false, because it uses the same regex to decide what counts as a conflict. On the uv pip compile path, the HelperSubprocessFailed is re-raised as is instead of becoming DependencyFileNotResolvable.

Build failures changed the same way in 0.12.14 (error: Failed to build ... followed by cause: lines), so they also come through with the raw output.

Native package manager behavior

uv itself behaves correctly; only the wording of the error changed in 0.12.14.

Images of the diff or a link to the PR, issue, or logs

Reproduced on main with the real uv 0.12.18 from dependabot/dependabot-core-development-uv, no stubs. I ran into this while working on #16509.

Smallest manifest that reproduces the issue

The pyproject.toml above, then update opentelemetry-api to 1.26.0.