[Mikola Lysenko (mikolalysenko)]

Problem

When uv 0.13.2 shipped (2026-10-19), it started refusing the pylock that Pipenv writes:

pipenv 2026.8.0 use_pylock: `uv pip install -r pylock.toml` failed: exit Some(2)
error: The target environment is not supported by the lockfile

That turned the Pipenv pylock legs red (nightly 39376690526) and stalled the merge queue for 2.7 h (#1645). Since then CI has pinned setup-uv to 0.13.1 in ci.yml and pipenv-compatibility.yml. #1639 proposed the same pin and was closed with a maintainer's note: "We should try to adapt to the upstream changes rather than pin to the current version." The pin on main is that same workaround, and it keeps CI on a uv release that is now four versions old.

Root cause

Pipenv writes environments = [] into pylock.toml, and uv 0.13.2+ reads an empty list as "no environment is supported". Checked locally against a freshly generated Pipenv pylock:

tool	Pipenv 2026.8.0 / 2026.10.2 pylock
uv 0.13.1	installs
uv 0.13.2 … 0.13.5 (latest)	error: The target environment is not supported by the lockfile
pip 25.3, 26.0	can't read pylock via -r
pip 26.1, 26.2.2 (latest)	installs

The latest Pipenv (2026.10.2) still writes environments = []. So this is a disagreement between Pipenv and uv, not something socket-patch's wiring causes.

Fix

Test only: crates/socket-patch-cli/tests/e2e_vex_build/pipenv.rs. The #1368 check, "a PEP 751 installer reading the wired pylock gets the PATCHED six", now runs two installers:

• pip 26.2.2 installs the wired pylock and must import the PATCHED six. Its result is recorded under the existing pylock-install-patched step.
• uv installs the wired pylock too. If uv accepts it, uv must also import the PATCHED six (pass). If uv refuses it, it must refuse Pipenv's untouched pylock with the same error: lines (upstream-refused). The wiring can therefore never be the cause of a uv refusal, and the test recovers on its own if uv or Pipenv changes.

Workflows: both setup-uv pins move from 0.13.1 to the current 0.13.5. They stay exact, because scripts/check-tool-pins.py requires an exact version and that rule exists because of #1645. Only the stale comment ("bump deliberately…") is reworded.

No test is removed or moved. Required-check names and ci-ok are unchanged.

Also ported: #1710's test-only Windows fix for global_folder_values_read_like_yarn (19b868d). Without it, this PR's full-scope run fails on the same Windows test main's nightly fails on. Once #1710 merges, that commit has no effect.

Proof

Local runs with SOCKET_PATCH_PIPENV_E2E_REQUIRED=1 SOCKET_PATCH_PIPENV_E2E_VERSIONS=2026.8.0, test pipenv::pipenv_pylock_projects_wire_what_pipenv_installs:

• uv 0.13.5: ok. The pip step gives pylock-install-patched: pass, and the uv step gives pylock-uv-install: upstream-refused.
• uv 0.13.1: ok. Both steps give pass, so the uv-accepting branch still checks the PATCHED bytes.
• Rest of the legs this pin feeds, on uv 0.13.5: pipenv:: and pip:: with SOCKET_PATCH_PIP_E2E_VERSIONS=26 gave 4 passed.
• scripts/check-tool-pins.py passes on both workflows, test_check_tool_pins passes, and cargo fmt --check is clean on the touched file.
• Clippy reports nothing in pipenv.rs. --all-targets does flag poetry.rs:485 (needless_borrows_for_generic_args), which this PR doesn't touch.
• actionlint and zizmor aren't installed in this session. Both workflow files parse as YAML.

These legs run only in the full-scope tier, so lean PR CI doesn't exercise them. I dispatched full-scope run 40119121674 on a47787c. With uv 0.13.5, every Pipenv leg has passed: 2022.12.19, 2023.12.1, 2024.4.1, 2025.1.3 and 2026.8.0, the last being the pylock one. The pip 22–26 leg has passed too. When I wrote this, 166 jobs had succeeded, none had failed, and 20 were still running.

Merge-queue / CI health at the time of this run (2026-10-24 ~17:40 UTC)

• Merge queue empty. The last 10 merge_group runs all succeeded, with no evictions in 24 h.
• 0 queued and 0 in-progress runs.
• Main pushes are green. The 10-24 nightly is red only on test (windows-latest, 1), which CI: fix Windows nightly yarnrc path expectation (#1689) #1710 fixes and which is waiting on review.

https://claude.ai/code/session_01PwwQCHPjEtXHWXW4SqeBh7

---

Note

Low Risk
Changes are CI pins, e2e test logic, and a platform-specific unit-test expectation; no production patch or install behavior.

Overview
Replaces the CI workaround that pinned uv at 0.13.1 with an updated e2e assertion model, then bumps uv to 0.13.5 in ci.yml and pipenv-compatibility.yml (still exact pins per check-tool-pins).

The Pipenv PEP 751 / pylock leg in pipenv.rs now validates wiring with pip 26.2.2 (pylock-install-patched) and separately exercises uv. If uv installs the wired lockfile, the install must still carry the PATCHED six; if uv rejects it (e.g. environments = []), the test records upstream-refused only when uv rejects Pipenv’s pristine pylock with the same error: lines—so socket-patch wiring cannot be blamed for uv’s refusal. Helpers pylock_install and error_lines support that split.

Also adjusts global_folder_values_read_like_yarn in yarnrc_tests.rs so escaped global-folder paths match Windows path.resolve behavior (ported from #1710).

^{Reviewed by Cursor Bugbot for commit 19b868d. Configure here.}

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

In the full-scope dispatch 40119121674, test (windows-latest, 1) and therefore ci-ok failed. The failing test is patch::redirect::yarnrc::tests::global_folder_values_read_like_yarn at yarnrc_tests.rs:594.

That failure isn't caused by this PR: main's 10-24 nightly fails the same test the same way. #1710 fixes it and is waiting on review. Its full-scope run on a real Windows runner was green. I ported its test-only change here in 19b868d. Once #1710 merges, that change has no effect.

Every Pipenv and pip leg this PR affects passed in that dispatch. I haven't started a second 187-job full run just to re-check Windows, because #1710 already proved that change on Windows.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

bugbot run

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 19b868d. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Labeled Ready for review by the burn-down agent.

• Head: 19b868d343ed161bd03144bd73a98918e41d335d
• CI: 37/37 green on lean PR CI (19 skipped by scope). Full-scope Pipenv and pip legs passed in run 40119121674.
• Main-wide: test (windows-latest, 1) (global_folder_values_read_like_yarn) fails on main's nightly. CI: fix Windows nightly yarnrc path expectation (#1689) #1710 fixes it, and this PR carries a test-only port of that fix (19b868d).
• Bugbot: reviewed 19b868d, no new issues. No open review threads.
• Mergeable against main, no conflicts.
• Reviewer focus: the uv 0.13.2+ upstream-refused branch in e2e_vex_build/pipenv.rs, and dropping the uv 0.13.1 pin in the two workflows.

Slack announcement not sent this run (no send tool available); the next run retries.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. Drops CI's uv 0.13.1 pin (a workaround the maintainer rejected on #1639) and adapts the Pipenv pylock e2e test instead. pip 26.2.2 now has to install the wired pylock.toml and import the PATCHED six. uv has to do the same, unless it refuses Pipenv's own untouched pylock with the same error: lines; uv 0.13.2+ reads Pipenv's environments = [] that way. Both workflows pin uv 0.13.5 exactly. It also carries #1710's one-line Windows test fix, byte-identical to #1710, so the two won't conflict.

Risk: low. It only touches CI pins and test code. Nothing in the shipped CLI changes.

Look here

• pipenv.rs:460: pip is now the oracle that has to install the PATCHED wheel (the Vendored mode leaves a Pipenv-written pylock.toml or a uv-export requirements.txt unpatched beside the wired lock #1368 guarantee).
• pipenv.rs:474-503:`` uv either installs PATCHED bytes or refuses exactly as it refuses the pristine pylock.
• pipenv.rs:518: pylock_install helper (pip pinned ==26.2.2).
• ci.yml:1509 and pipenv-compatibility.yml:108: 0.13.1 → 0.13.5.

Verified

• Read the full diff. pristine_pylock is the lock captured before wiring (L384).
• The yarnrc hunk is identical to CI: fix Windows nightly yarnrc path expectation (#1689) #1710's.
• No CHANGELOG.md change and no unrelated edits.
• Required checks green on the head (ci-ok ✅, clippy ✅), with 38 check runs succeeding.
• Bugbot: no issues. 0 unresolved threads.
• Full-scope run 40119121674 on a47787c: 249 of 251 jobs passed or were skipped, including every Pipenv leg (pylock included) and pip 22–26. The only failures are test (windows-latest, 1) (the socket-patch-core --lib yarnrc test that the head's port of CI: fix Windows nightly yarnrc path expectation (#1689) #1710 fixes) and ci-ok, which follows from it.

Changes I made: none.

Open questions: none blocking. One note: if uv ever failed for an unrelated reason (e.g. network) on both pylocks with identical error: lines, the uv step would record upstream-refused. The pip step still guards the wiring, so I left it as is.

Auto-merge (squash) is armed, so approving sends it straight to the merge queue.

---

Generated by Claude Code