GeezerVison

BugBot review

Generated by Claude Code

Labeled Ready for review (burn-down agent).

• Head: 1b96ed7
• CI: 86/86 green (36 success, 50 skipped). No main-wide failures.
• Bugbot: reviewed 1b96ed7, no findings. 0 open threads.
• Mergeable with no conflicts. CHANGELOG.md is not touched.
• Reviewer focus: requirements pin spelling normalization in vex/discover/pypi_other.rs and vendor/lock_inventory/pypi.rs, plus the CLI_CONTRACT.md wording.

Slack announcement not sent this run (the Slack send tool was unavailable). The next run will retry.

Generated by Claude Code

The merge queue dequeued this PR because a CI check failed. The failure isn't this PR's.

• Failing check: e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0), test pipenv::pipenv_pylock_projects_wire_what_pipenv_installs. Error: uv pip install -r pylock.toml → The target environment is not supported by the lockfile.
• Why it isn't this PR's: queue runs for Fix lock rewrites changing file owner (#1635) #1636 and Fix vlt vendoring of prepare-family scripts (#1633) #1637 fail the same leg. setup-uv installs the latest uv. uv 0.13.2 and later refuse the environments = [] pylock that Pipenv 2026.8.0 writes. I reproduced it locally: uv 0.13.1 installs the file (+ six==1.16.0) and 0.13.4 refuses it.
• Fix ported: d72ed0d copies Fix nightly Pipenv pylock legs broken by uv 0.13.2 #1639's uv pin (version: "0.13.1" on both setup-uv steps). It becomes a no-op once Fix nightly Pipenv pylock legs broken by uv 0.13.2 #1639 merges.

The PR needs to be re-queued after CI on d72ed0d passes. The push may also have dismissed the earlier approval.

Generated by Claude Code

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

Besides merges from main, the only new commit is d72ed0d: 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 d72ed0d0 is all this needs.

Generated by Claude Code

bugbot run

Generated by Claude Code

Ready for review re-confirmed at the new head (burn-down agent).

• Head: d72ed0d
• CI: 54/54 green (35 success, 19 skipped). No main-wide failures.
• Bugbot: reviewed d72ed0d, no findings; no unresolved review threads.
• Mergeable: clean. The head changed after the earlier approval (main merges plus the setup-uv pin port), so it needs a fresh approval before re-queueing.
• Slack: not announced this run (send tool unavailable); the next run will retry.

Generated by Claude Code

The merge queue dequeued this PR again. The uv pin worked: the pipenv:: leg passed. This time a different check failed, and it isn't this PR's either.

• Failing check: coverage (run 39655972927). Test vendor::pypi_hatch::tests::hatch_on_an_absolute_path_entry_passes_the_version_gate failed with pypi_hatch_unsupported ("require Hatch >=1.2 on PATH").
• Why it isn't this PR's: this PR doesn't touch vendor/pypi_hatch.rs. In the same queue the run for Fix uv restore ignoring lock file filters (#1604, #1613) #1614 passed coverage, and Fix uv restore ignoring lock file filters (#1604, #1613) #1614 sits behind this PR, so its merge group contains this PR's changes. The same code passed once and failed once.
• Likely cause: fake_hatch writes a shell script, and the probe then execs it right away. If a parallel test thread forks while the script's write fd is still open, the exec fails with ETXTBSY ("Text file busy"). require_environment_context_support_with turns a spawn error into None via .ok(), which produces exactly this refusal. The repo already handles this race in other places (utils/process.rs output_of_fresh_shim, update/download.rs), but not in the Hatch tests.
• No fix exists yet (CI: pin floating toolchain versions (#1645) #1647 only pins CI tools). Proposed patch, test-only, in crates/socket-patch-core/src/vendor/pypi_hatch.rs:

     fn fake_hatch(dir: &Path, marker: &Path) {
         use std::os::unix::fs::PermissionsExt;
         let script = dir.join("hatch");
         std::fs::write(
             &script,
             format!(
                 "#!/bin/sh\n: > '{}'\necho 'Hatch, version 1.13.0'\n",
                 marker.display()
             ),
         )
         .unwrap();
         std::fs::set_permissions(&script, std::fs::Permissions::from_mode(0o755)).unwrap();
+        // Wait out the fork/exec ETXTBSY window (a sibling test thread can
+        // still hold our write fd), so the probe under test never sees it.
+        let deadline = std::time::Instant::now() + std::time::Duration::from_secs(10);
+        loop {
+            match std::process::Command::new(&script).output() {
+                Ok(_) => break,
+                Err(e)
+                    if e.kind() == std::io::ErrorKind::ExecutableFileBusy
+                        && std::time::Instant::now() < deadline =>
+                {
+                    std::thread::sleep(std::time::Duration::from_millis(20));
+                }
+                Err(e) => panic!("spawn the fake hatch: {e:?}"),
+            }
+        }
+        let _ = std::fs::remove_file(marker);
     }

Removing the marker after the priming run keeps the "the resolved hatch was not run" assertion meaningful.

Re-queueing this PR is the one re-run. If coverage fails the same way again, the race is real and needs the patch above.

Generated by Claude Code

Burn-down agent: #1599 landed on main and conflicted with this PR in crates/socket-patch-core/src/vex/discover/pypi_other.rs. Both sides only added tests, so I kept all of them and merged main (b7fe9a2) in as 3417797. vex::discover tests pass (417/417). I removed Ready for review; it goes back on once CI is green on the new head.

Generated by Claude Code

bugbot run

Generated by Claude Code

Burn-down agent: re-labeled Ready for review at 3417797 (the merge of main described above).

• CI: 34/34 green, 19 skipped.
• Bugbot: its check passed on this head and no review threads are open.
• No code changes since the last review besides the conflict resolution (tests only). The pypi_hatch ETXTBSY flake patch proposed above is still unmerged, so a re-queue may trip it again.

Generated by Claude Code