GeezerVison

BugBot review

Generated by Claude Code

BugBot review

Generated by Claude Code

Labeled Ready for review at head 827cac5.

• CI: 35/35 checks green (19 skipped). No main-wide failures.
• Mergeable against main, no conflicts. CHANGELOG.md is untouched.
• Bugbot: reviewed 827cac5, no new issues. The one earlier thread (on uv.rs) is resolved.
• What to look at: the restore guard in crates/socket-patch-core/src/patch/redirect/upstream/uv.rs, which now refuses rebuilding a lock entry when [options.exclude-newer-package] or a uv pip compile pylock's build filters could have dropped files, and the matching CLI_CONTRACT.md text.
• Slack announcement could not be sent this run (the Slack send tool is not available); the next run will retry.

Generated by Claude Code

[agent] uv bug-hunt verification (ledger #310) of head 827cac5 against real uv on Linux, using the bughunt mock patch server (six 1.16.0 and colorama 0.4.4 patches).

Fixed by this PR (main 657fce2 fails each of these, the PR passes):

Gaps left (each reproduced on uv 0.11.32 and 0.13.1, once with rollback and once with remove, both exit 0 and the restored pylock gains six's sdist):

1. uv pip compile --no-header --no-build. pip_compiled recognises the lock by the missing index, but there's no command line to read, so compile_filter finds nothing. The lock does show the filter: no sibling (attrs) has an sdist either.
2. UV_CUSTOM_COMPILE_COMMAND="make lock" uv pip compile --only-binary six. The header reads # make lock, so uv_header_command returns None and the flags are lost the same way.
3. A user-level $XDG_CONFIG_HOME/uv/uv.toml with [pip] no-build = true or only-binary = ["six"]. uv applies it to uv pip compile (the original pylock has no six sdist), but pip_settings only walks up from the lock's directory. The same likely applies to /etc/uv/uv.toml (not tested).

For 1 and 2, the safe option seems to be refusing a pip-compiled pylock whose command line isn't recorded, or one whose siblings show the filter. For 3, reading uv's user and system config the way uv does would cover it, or else document the gap. UV_NO_BUILD=1 / UV_ONLY_BINARY=six turned out not to filter what uv pip compile records on 0.13.1 (the six sdist is kept), so env vars aren't a gap.

printf 'six==1.16.0\nattrs==24.2.0\n' > req.in
uv pip compile -q req.in --no-build --no-header --format pylock.toml -o pylock.toml --python-version 3.11   # gap 1
# gap 2: UV_CUSTOM_COMPILE_COMMAND="make lock" uv pip compile -q req.in --only-binary six --format pylock.toml -o pylock.toml --python-version 3.11
# gap 3: XDG_CONFIG_HOME=$PWD/xdg with xdg/uv/uv.toml = '[pip]\nno-build = true', then a flagless compile
cp pylock.toml orig.toml; uv venv -q && uv pip sync -q pylock.toml
socket-patch scan --mode hosted --yes; socket-patch rollback pkg:pypi/[email protected]   # exit 0
diff orig.toml pylock.toml   # > sdist = { url = ".../six-1.16.0.tar.gz", … }

Generated by Claude Code

[agent] All three gaps from the ledger #310 verification are closed in 64e40c4:

1. and 2. A uv pip compile pylock whose header doesn't record a uv pip compile command line is now refused. That covers --no-header, UV_CUSTOM_COMPILE_COMMAND="make lock", and a custom command that starts with uv such as uv run poe lock. I did not use the sibling-shape heuristic, because --only-binary six leaves no trace on the siblings.
2. Pylock restores now also read the user-level uv.toml ($XDG_CONFIG_HOME/uv, ~/.config/uv or %APPDATA%\uv) and the first system-level one ($XDG_CONFIG_DIRS, else /etc/uv, or %PROGRAMDATA%\uv on Windows). They merge as uv merges them: lists add up across files, per-package cutoffs merge entry by entry, and [pip] wins over the top level. UV_NO_CONFIG skips them.

The golden test and two new unit tests cover these cases. The golden suite (53/53) and e2e_redirect_uv_build (9/9) pass.

Generated by Claude Code

BugBot review

Generated by Claude Code

BugBot review

Generated by Claude Code

BugBot review

Generated by Claude Code

Still Ready for review, now at head 7dae64f. The label was first applied at an earlier head.

• CI: 54/54 checks on 7dae64f passed (35 succeeded, 19 skipped). No checks are failing on main.
• Mergeable against main with no conflicts. CHANGELOG.md is not changed.
• Bugbot reviewed 7dae64f and found nothing new. All 3 review threads are resolved.

Generated by Claude Code

[agent] uv bug-hunt re-verification (ledger #310) of head 7dae64f on Linux with real uv, using the bughunt mock patch server (six 1.16.0 and colorama 0.4.4 patches). Each cell: uv pip compile … --format pylock.toml, uv pip sync, scan --mode hosted, then rollback.

Closed by 7dae64f. On main 7d3086f each of these exits 0 and re-adds the sdist. On the PR each one gives hosted_restore_refused and leaves the lock wired:

A plain compile still restores byte-identically, so nothing is over-refused.

Two gaps remain. Both reproduce twice on the PR, exit 0, and add colorama-0.4.4.tar.gz back to a lock that didn't have it:

1. UV_EXCLUDE_NEWER. From uv 0.12.24 on (0.12.24, 0.13.0 and 0.13.1 checked; 0.12.0 and 0.11.33 keep every file), UV_EXCLUDE_NEWER=2020-10-14T00:00:00Z uv pip compile … drops colorama 0.4.4's sdist (uploaded 2020-10-15) from the pylock. The header doesn't record the env var (# uv pip compile req.in --format pylock.toml -o pylock.toml --python-version 3.11), so compile_filter finds nothing. It fails the same way whether or not the variable is still set when rollback runs, and remove fails the same way (hosted_reverted, sdist added). The --exclude-newer flag is refused, as expected.
2. UV_CONFIG_FILE pointing at a file with exclude-newer = "…", which is the env form of --config-file. uv applies it and the sdist is filtered out, but restores aren't refused. The PR body says UV_CONFIG_FILE isn't followed. Given that --config-file refuses, refusing when UV_CONFIG_FILE (or UV_EXCLUDE_NEWER / UV_EXCLUDE_NEWER_PACKAGE) is set in the environment seems the consistent choice. It's only a proxy for the compile machine, but the user/system-config read already makes the same trade.

UV_EXCLUDE_NEWER_PACKAGE=colorama=… didn't filter uv pip compile on 0.11.32 / 0.13.1 (the sdist was kept), so I'm not counting it as a gap.

printf 'colorama==0.4.4\nsix==1.15.0\n' > req.in
UV_EXCLUDE_NEWER=2020-10-14T00:00:00Z uv pip compile -q req.in --format pylock.toml -o pylock.toml --python-version 3.11   # uv 0.13.1
cp pylock.toml orig.toml; uv venv -q && uv pip sync -q pylock.toml
socket-patch scan --mode hosted --yes; socket-patch rollback pkg:pypi/[email protected]   # exit 0
diff orig.toml pylock.toml   # > sdist = { url = ".../colorama-0.4.4.tar.gz", … }

Generated by Claude Code

[agent] The merge queue dropped this PR because e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0) failed. The test that failed is pipenv_pylock_projects_wire_what_pipenv_installs, at the uv pip install -r pylock.toml step: "The target environment is not supported by the lockfile". This failure is not caused by this PR. The same job fails in the queue runs for #1620, #1622 and #1625. The cause is uv 0.13.2, which refuses the environments = [] that Pipenv 2026.8.0 writes, because setup-uv installs the latest uv. #1639 is the fix.

I ported #1639's change into this PR in 8b5c53a: setup-uv is pinned to version: "0.13.1" in ci.yml and pipenv-compatibility.yml, identical to #1639. I also merged main in 19d0f4c. The pin becomes a no-op once #1639 lands. The golden suite (53/53) and the uv unit tests pass on the merged tree.

The push resets the approval at 8805144, so this needs re-approval and a re-queue once CI is green.

Generated by Claude Code

Wenxin Jiang (@Wenxin-Jiang) this changed after your approval (on 88051442), so it needs another look before it goes through the merge queue.

Besides merges from main, the only new commit is 8b5c53a: the CI-only uv pin from #1639 (version: "0.13.1" on the setup-uv steps in ci.yml and pipenv-compatibility.yml, 12 added lines, byte-for-byte the same as #1639). No crate code changed. Without it the pipenv:: e2e leg fails in the merge queue on uv 0.13.2+. It no-ops once #1639 lands.

If that's fine with you, re-approving 8b5c53a7 is all this needs.

Generated by Claude Code

bugbot run

Generated by Claude Code

BugBot review

Generated by Claude Code

Wenxin Jiang (@Wenxin-Jiang) one more code change landed after your approval (on 88051442) and after the uv-pin note above, so this needs another look before it goes into the merge queue.

Besides merges from main and the CI-only uv pin (8b5c53a, explained above), the new commit is bc8597e "Let a false exclude-newer-package exempt its package" (upstream/uv.rs +124/−69, a golden test, one CLI_CONTRACT.md line). In uv, exclude-newer-package = { pkg = false } takes that package out of the global exclude-newer cutoff, but restores still refused it. Now a false entry exempts the package wherever the global cutoff came from: the uv.lock [options], uv pip compile --exclude-newer-package pkg=false, uv settings, or UV_EXCLUDE_NEWER. A non-false per-package cutoff still refuses. CI is green on the head (bc8597ee) and Bugbot is clean.

If that's fine with you, re-approving bc8597ee is all this needs.

Generated by Claude Code

Burn-down agent: labeled Ready for review at bc8597e.

• CI: 55/55 check runs settled green on this head (36 success, 19 skipped, ci-ok success). No main-wide failures.
• Bugbot: reviewed bc8597e. All 5 of its threads are resolved, and none are open.
• Mergeable: merges cleanly into current main, and no CHANGELOG.md change.
• Reviewer focus: this needs a fresh approval at bc8597e. The earlier approval was on 8805144. The latest commit makes a false exclude-newer-package entry exempt that package from the global cutoff, in uv.rs.

Slack announcement not sent: this run has no Slack send tool.

Generated by Claude Code

Labeled Ready for review (burn-down agent).

• Head: bc8597e. Mergeable, no conflicts; CHANGELOG.md not touched.
• CI: 55/55 checks green on the head (36 success, 19 skipped by path filters). No main-wide failures.
• Bugbot: reviewed bc8597e, no new issues; 0 open review threads.
• Reviewer focus: the approval on 8805144 predates the CI-only uv pin (8b5c53a) and the restore-filter fix (bc8597e) explained above, so it needs a fresh approval before the merge queue.

Generated by Claude Code