GeezerVison

Assisted-by: Claude Code:claude-opus-5-5

After vendoring, an ordinary uv relock (`uv add --dev x`, `uv add y`)
re-serializes the lock arrays that hold our element: the dev group's
requires-dev line and `[manifest] overrides`. Revert matched those
arrays by their exact recorded text, so it saw drift and kept
uv.lock wired, but still reverted pyproject.toml. The pair then
failed `uv sync --locked` while `vendor --revert` reported success.

Revert now finds our unchanged element inside the live array under
the same key and restores or removes just that element, rendering
the array the way uv writes it. A pair gate also writes neither
file when any record is genuinely drift-kept, so pyproject.toml and
uv.lock always stay consistent.

Fixes #806, #821.

Assisted-by: Claude Code:claude-opus-5-5

Vendor six, run the uv command that re-serializes the lock array
around our element (`uv add --dev zipp` for a dev group, `uv add
idna` beside user overrides), then revert. Both files must be
unwired with no drift warning, and `uv lock --check` must pass.

Refs #806, #821.

Assisted-by: Claude Code:claude-opus-5-5

Refs #806, #821.

Assisted-by: Claude Code:claude-opus-5-5

A [manifest] overrides record holds the bare array, and the old
convergence shortcut searched the whole lock for it. When the root
requires-dist happened to match the user's overrides array, revert
treated our element as already gone, left it in uv.lock and deleted
the artifact it points at. Every whole-array record now reverts
through its own key: an untouched array is restored verbatim,
otherwise just our element is.

Refs #806.

Assisted-by: Claude Code:claude-opus-5-5

Revert treated any miss locating a whole-array record as convergence,
including a key spelled differently or an unbalanced array. A lock
that still routed through the vendored wheel could then lose the
wheel. Only a key or section that is provably absent now counts as
converged. Anything unreadable is drift, which keeps both files and
the artifact.

Refs #806, #821.

Assisted-by: Claude Code:claude-opus-5-5

Assisted-by: Claude Code:claude-opus-5-5

A vendored uv revert writes back the lock specifier it recorded when
vendoring. If the user changed the package's requirement in
pyproject.toml in the meantime, the lock no longer matches and
`uv sync --locked` fails. These tests pin the expected behaviour
for requires-dist, requires-dev groups and [manifest] constraints.

Refs #840

Assisted-by: Claude Code:claude-opus-5-5

When six is vendored, uv.lock records it as a path source with no
version specifier. If the user then changes six's requirement in
pyproject.toml (uv add "six>=1.16"), the lock stays byte-identical,
and vendor --revert, remove and rollback wrote back the specifier
recorded at vendoring time. The revert reported success, but
`uv sync --locked` then failed.

The revert now writes the specifier pyproject.toml declares now, using
the same derivation the hosted unwind uses. This covers requires-dist
(each extra separately), requires-dev groups and [manifest]
constraints. An unchanged declaration still restores byte-for-byte.
When uv's spelling can't be derived, such as a multi-clause range whose
clause order varies between uv releases, the revert keeps both files
and warns vendor_lock_entry_drifted instead of breaking the lock.

Fixes #840

Assisted-by: Claude Code:claude-opus-5-5

Refs #840

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

#625 on main changed the uv declaration reader to report each
optional-dependencies member's extra. The merge of main into this branch
no longer compiled. Use that reader for requires-dist instead of the
local extras walk. Dev groups now also pick up main's group-name
normalization and include-group expansion.

Refs #840

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

When a package is declared twice, for example under two environment
markers, or directly and through an include-group, the revert kept the
recorded specifier whenever any one declaration still matched it. Edit
just one of them and the stale pin came back, with the same broken
`uv sync --locked` as #840.

The revert now picks the declaration by the entry's own marker, as the
hosted unwind does. Declarations that still disagree after that are
treated as drift, and both files are kept.

Refs #840

Assisted-by: Claude Code:claude-opus-5-5

#822 landed on main as a squash commit. The conflicts with this
branch's copy of #822's commits are resolved by three-way merging
against #822's head (77686c4), so only this PR's own changes remain on
top of main.

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Two cases Bugbot found on the vendored uv revert:

- A same-name declaration that isn't a plain version range, such as an
  extra pinned with ===, stopped every entry from following its edited
  declaration. Now only the entry whose own declaration is unreadable
  keeps its recorded spelling.
- After a bound was dropped, the restored { name = "six" } element
  also matched another dependency entry in uv.lock, so a drifted wiring
  could pass as already reverted. The check now looks only in the root
  unit's requires-dist array.

Refs #840

Assisted-by: Claude Code:claude-opus-5-5

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

main has been red since #605 (4646693). Two vex_consumed tests from
#738 assumed the name-keyed copy resolver never returns npm-aliased
copies, and #605 taught it to. This ports #851's tests-only fix
unchanged so this PR's coverage and macOS test jobs can go green; it
no-ops once #851 lands on main.

Assisted-by: Claude Code:claude-opus-5-5

cursor Bot left a comment