[Mikola Lysenko (mikolalysenko)]

Problem

The nightly CI on main (schedule run 39376690526, head 14eee88b) is red and fails ci-ok. Two legs failed, both in the same test:

• e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0)
• e2e-macos (macos-latest, e2e_vex_build, pipenv:: --ignored, 2022.12.19 2026.8.0)

pipenv::pipenv_pylock_projects_wire_what_pipenv_installs ... FAILED
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

The previous night's run on 7d3086f1 passed. The two commits in between (#1429, #1592) don't touch Pipenv or the pylock code.

Root cause

Pipenv 2026.8.0 writes environments = [] into the pylock.toml it generates. uv 0.13.2, published to PyPI on 2026-10-19 at 20:59 UTC, now reads an empty environments list as "no environment is supported" and refuses to install. astral-sh/setup-uv with no version: installs the latest uv, so the uv that checks this test's result changed while main stayed the same. Every other workflow here already pins uv (uv==0.11.19). The two setup-uv steps did not.

Tested locally against the pylock that Pipenv 2026.8.0 generates (uv pip install --dry-run -r pylock.toml):

uv	result
0.11.19, 0.11.30, 0.11.31, 0.13.1	+ six==1.16.0
0.13.2, 0.13.3, 0.13.4	error: The target environment is not supported by the lockfile

Fix

Pin setup-uv to version: "0.13.1", the last uv these legs passed on, in:

• ci.yml: the "Setup uv (Pipenv / pip legs)" step
• pipenv-compatibility.yml: the "Install uv" step, which has the same exposure

A comment next to each pin says why it is there, and that it should only be bumped after checking the Pipenv pylock legs.

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

Proof

I built e2e_vex_build locally and ran pipenv::pipenv_pylock --ignored with SOCKET_PATCH_PIPENV_E2E_VERSIONS=2026.8.0:

• with uv 0.13.4 on PATH: FAILED, the same target environment is not supported error as CI
• with uv 0.13.1 on PATH: test result: ok. 1 passed

Both workflow files parse as YAML. actionlint and zizmor are not installed in this session.

Follow-up (not in this PR)

Pipenv's environments = [] is a real interoperability problem: users who install a Pipenv pylock with uv ≥ 0.13.2 will hit it too, with or without socket-patch. Someone should decide whether to report it to Pipenv or uv, and when to move the pin forward.

---

Generated by Claude Code

---

Note

Low Risk
Workflow-only pin to restore CI; no application or security logic changes.

Overview
Pins uv to 0.13.1 on the two CI workflows that used unpinned astral-sh/setup-uv for Pipenv/pip and pylock legs (ci.yml “Setup uv (Pipenv / pip legs)” and pipenv-compatibility.yml “Install uv”).

uv 0.13.2+ treats Pipenv 2026.8.0’s environments = [] in pylock.toml as unsupported and fails uv pip install -r pylock.toml, which broke nightly Pipenv pylock e2e. Inline comments document the pin and that bumps should follow a deliberate pylock-leg check.

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

---

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 a7c9207. Configure here.}

[Mikola Lysenko (mikolalysenko)]

This PR is now also the merge-queue blocker, not just a nightly fix. The e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0) leg runs in merge_group, so every queue head fails with the same uv pip install -r pylock.toml → The target environment is not supported by the lockfile error and gets evicted:

PR	added	removed	failing merge_group CI run
#1599	15:51	16:19	39455777018
#1605	15:51	16:25	39456462502
#1609	15:51	16:32	39457353757
#1612	15:51	16:39	39458310970

Main hasn't moved from 14eee88 since. Every remaining entry (#1614, #1622, #1625, #1628, …) will fail the same way until this pin lands, because none of them touch ci.yml. I reproduced it locally too: the test fails with uv 0.13.4 and passes with 0.13.1. uv 0.13.2's changelog says "Honor PEP 751 environment restrictions when installing or syncing from pylock.toml" (astral-sh/uv#22594).

Suggest reviewing this first and putting it at the front of the queue. Its own merge_group run carries the pin, so it passes.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Final review brief

What it does. Pins astral-sh/setup-uv to uv 0.13.1 in the two workflow steps that had no version pin. uv 0.13.2 (out 2026-10-19) rejects the environments = [] pylock that Pipenv 2026.8.0 writes, so the pipenv:: e2e leg fails on the nightly and on every merge-queue entry. The queue hasn't merged anything since 2026-10-19 13:26, because each head gets evicted about 7 minutes in.

Risk: low. CI config only: 12 added lines, no crate code. Every other workflow already pins uv (uv==0.11.19).

Look here

• ci.yml:1465-1473
• pipenv-compatibility.yml:102-109

Verified. Read the full diff. CI is 36 passed / 19 skipped / 0 failed on the head. The e2e (ubuntu-latest, e2e_vex_build, pipenv:: --ignored, 2026.8.0) leg, the one breaking the queue, is green here. Cursor Bugbot is green. No review threads. CHANGELOG.md is untouched. #1591, #1593, #1599, #1605 and #1612 carry the identical change.

Changes I made. None.

Open questions. None. This is the most urgent approval in the repo. Once you approve, enqueueing it with "jump to front" (or dequeuing the queue entries that don't have the pin) stops the queue evicting every entry ahead of it. I can't do either from a cloud session, because GraphQL is blocked here.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

Labeled Ready for review.

• Head: a7c9207cfa32baa780953b7dd24593dae64de898. It merges cleanly into main (14eee88).
• CI: 36 of 36 checks that ran are green (19 skipped by path filters). That includes the pipenv:: --ignored, 2026.8.0 leg that breaks the merge queue.
• Bugbot: reviewed this head, no findings. No open review threads.
• CHANGELOG.md is not touched.

Reviewers: this is a CI-only uv pin, and it unblocks the merge queue. Please review it before the other queued PRs.

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

[final reviewer] This PR looks superseded. Its whole change (the setup-uv version: "0.13.1" pin in ci.yml and pipenv-compatibility.yml) is already on main. It landed with #1605 (aea79f5), which carried a port of this commit. Merging a7c9207 into main a54753a gives a tree identical to main (git merge-tree --write-tree origin/main a7c9207 then git diff --stat origin/main <tree> is empty), and the e2e … pipenv:: --ignored, 2026.8.0 leg is green on main.

I haven't armed auto-merge because a squash would be empty. Labelled agent:needs-human: a maintainer should close it as superseded by #1605 (agents don't close PRs).

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

CI janitor check (2026-10-21 11:50 UTC): this PR is now a no-op against main. The same version: "0.13.1" pins in ci.yml and pipenv-compatibility.yml landed on main in aea79f5 (the #1605 squash). A trial merge of this head into origin/main gives a tree identical to main. The nightly pylock legs also pass again: the 2026-10-21 nightly, run 39551481612, was green.

Recommend closing this PR as superseded. Nothing in it is left to merge.

---

Generated by Claude Code