Persist per-package exclude-newer exceptions for uv (pnpm-style), not just an ephemeral CLI flag

[alakae]

Tell us more.

Hi! Posting this because I'm genuinely stuck on the problem below and, as far as I can tell, it isn't solved yet, so I'm filing it as a feature request in case I'm missing something. If there's already a good workaround (or a reason this is intentionally out of scope), I'd love to hear it just as much as a "yes, let's build this."

Small disclaimer: this reflects my current best understanding of the landscape (uv's cooldown config, Renovate's minimumReleaseAge/vulnerabilityAlerts, and how the two interact) after digging through docs and issues. Happy to be corrected if I've got something wrong.

The problem

uv supports a dependency "cooldown" via exclude-newer in pyproject.toml/uv.toml, which makes uv ignore any package version uploaded within a configured duration (e.g. 7 days).

#41654 tracks passing --exclude-newer to uv, modeled on how Renovate already passes --before=<date> to npm during lock file generation: an ephemeral CLI flag, applied per invocation, written nowhere.

Renovate's own docs already recommend keeping this kind of setting in sync between Renovate and the package manager:

"We recommend specifying minimum release age in both your Renovate and package manager configuration." (Source: Minimum Release Age)

That guidance is about keeping the default cutoff aligned (so transitive dependencies pulled in during a delegated lockfile update don't slip past Renovate's own check). It doesn't cover the case below: a security-driven exception that needs to diverge from that default for one package, for one release.

That's the case #41654's ephemeral-flag design doesn't help with. Renovate's vulnerabilityAlerts config already bypasses minimumReleaseAge so it opens the PR immediately, but when it then shells out to uv pip compile to regenerate the lockfile, there's nothing that lets that specific update through while the rest of the project keeps respecting the cooldown. An ephemeral --exclude-newer flag, even if implemented, only relaxes the cutoff for the whole invocation, and isn't recorded anywhere uv reads on a subsequent plain resolve.

Concretely, this breaks any project that verifies its lockfile is up to date by re-resolving and diffing (e.g. a CI job running uv pip compile then git diff --exit-code requirements.txt, or uv lock --check). That's the common (?) way to catch a requirements.txt/lockfile that's drifted from its source, since there's no check that verifies consistency without re-resolving:

# Anti-pattern: ephemeral flag, nothing persisted
uv pip compile --exclude-newer-package "django=false" --upgrade-package django \
  requirements.in -o requirements.txt

# What we actually want committed instead: persisted, scoped to one release
[tool.uv]
exclude-newer = "7 days"
exclude-newer-package = { django = "2026-08-05T00:00:00Z" }

The first command produces a requirements.txt a plain recompile can't reproduce. The very next plain resolve, in CI or by another developer, fails, because nothing in the committed config explains why that version was allowed through. The second is what we'd want Renovate to commit for us.

What I'd like

For uv projects, when Renovate raises a security-driven update that falls inside the configured exclude-newer cooldown, have it write a scoped, persisted exception into pyproject.toml (or uv.toml) alongside the version bump, instead of (or in addition to) passing an ephemeral CLI flag (see the second snippet above).

This is the uv analogue of what Renovate now does for pnpm (renovatebot/renovate#40020): security updates get a minimumReleaseAgeExclude entry written into pnpm-workspace.yaml, a persisted exemption, not a CLI flag (pnpm docs). Applying the same pattern to uv via its native exclude-newer-package setting would mean:

• The exception is visible in the diff/PR, reviewable like any other config change.
• A plain uv pip compile / uv lock (no special flags) reproduces the same resolution, so CI drift checks stay green instead of failing on the very next resolve.
• The exception is scoped to the single patched release (a timestamp just past its upload time), not a permanent exemption: the next release is still subject to the normal cooldown.

Suggested behavior:

1. Pick a cutoff timestamp strictly after the target release's actual upload time (uv's comparison is sub-second, so round the cutoff forward a bit rather than copying the upload timestamp verbatim). This bit me during testing.
2. Write/update a single exclude-newer-package entry for the affected package in the same table as the existing exclude-newer setting (don't split exclude-newer and exclude-newer-package across [tool.uv] and [tool.uv.pip]).

Alternatives I've considered

• #41654, the an ephemeral CLI flag only (the currently tracked design). Solves nothing for projects with a re-resolve-based drift check: Renovate's own PR would become unreproducible the moment anyone else runs a plain uv lock/uv pip compile.
• Manual-only workaround: a human adds the dated exclude-newer-package entry by hand, with a comment noting the reason and a removal date, then regenerates the lockfile. Works, but defeats the point of using Renovate for security updates: someone still has to notice the CVE and write the config change themselves.
• exclude-newer-package = { pkg = false } (permanent exemption) instead of a dated cutoff. Rejected because it never expires: the next release of that package also bypasses the cooldown until someone remembers to remove the line.

Links

• Cooldown feature: https://docs.astral.sh/uv/concepts/resolution/#excluding-newer-distributions
• exclude-newer-package setting: https://docs.astral.sh/uv/reference/settings/#exclude-newer-package
• Renovate's recommendation to keep minimum release age in sync with the package manager: https://docs.renovatebot.com/key-concepts/minimum-release-age/
• Tracked ephemeral-flag approach: Pass --exclude-newer to uv #41654
• uv issue confirming the dated-config-entry pattern is the accepted (manual) workaround today, and requesting the cleanup/staleness tooling that's out of scope here: Prune stale exclude-newer-package entries on uv lock astral-sh/uv#18792

[alakae]

Small update: this also affects uv's native project mode (pyproject.toml [project] + uv.lock), not just the pip-compile interface. A CLI-only --exclude-newer-package override gets recorded in uv.lock's [options] table, but a plain uv lock still silently re-resolves it away since pyproject.toml doesn't explain it. In turn uv lock --check fails (exit 1) on this drift. So essentially the same problem as with the pip compile interface.

[schlamar]

There is an uv issue about this: astral-sh/uv#18775