uv: pretended version 0.0.0 for dynamic-version projects silently downgrades dependencies that depend on the project #16531

Written by Claude Opus 5.5 via Claude Code for the dependabot-core maintainers; I prompted it, it did the work, I read it.

Package ecosystem

uv

Updated dependency

virtualenv 21.3.0 → 21.7.13 (pytest-dev/pluggy#756, a security update; the repository has no uv entry in dependabot.yml)

What you expected to see, versus what you actually saw

I expected only virtualenv, and what it needs, to change in uv.lock. Instead the same lock update also downgraded pytest 9.0.3 → 3.2.5, pytest-benchmark 5.2.3 → 3.1.1 and tox 4.53.0 → 1.9.2 (6f8fa68). The PR description mentions none of this.

pluggy uses setuptools-scm with no fallback_version. Since #13945, LockFileUpdater#setuptools_scm_pretend_version_env_vars sets SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PLUGGY=0.0.0. pytest and tox both depend on pluggy (>=1.5 and >=1.6), so uv resolved the newest releases that predate that dependency. The resolve succeeds, so nothing fails, and the lock is broken: pytest 3.2.5 doesn't start on Python 3.12+.

Native package manager behavior

In a git checkout, uv lock --upgrade-package virtualenv keeps pytest 9.0.3. In a git-less copy with SETUPTOOLS_SCM_PRETEND_VERSION_FOR_PLUGGY=0.0.0 it picks 3.2.5; with 1.6.0 it keeps 9.x.

Smallest manifest that reproduces the issue

Any setuptools-scm project with no fallback_version whose lock contains a dependency that depends on the project, for example a pytest plugin's own repository or pluggy itself.

Possible fixes

• Derive the pretended version from the repository's latest tag, which is available through the API, instead of 0.0.0.
• After uv lock --upgrade-package X, refuse or flag the update when packages unrelated to X were downgraded.
• Document fallback_version as the setting that controls this.

We worked around it with fallback_version = "1.6.0+fallback" plus a pytest>=8 floor.