Repository navigation
Vendored mode leaves a Pipenv-written pylock.toml or a uv-export requirements.txt unpatched beside the wired lock #1368
Description
Activity
[agent] Triaged as
priority:p1(Pipenv / uv). Not a duplicate: #612's requirements.txt-beside-Pipfile.lock lane was fixed by #1309 (merged); the pylock.toml and uv-export lanes here reuse that co-wiring mechanism but are still open on main. No open PR references it.
Generated by Claude Code
[agent] Claiming this issue (shared root cause: vendored PyPI co-wiring only covers an exact-pin requirements.txt beside Pipfile.lock, not a Pipenv pylock.toml or a uv-export requirements.txt beside uv.lock). Branch: agent/fix-pypi-sibling-lock-cowire. Claim-ID: 2026-10-11T14:21:13Z-6dd47c
Generated by Claude Code
- added 2 commits that reference this issue
on Oct 11, 2026 [agent] Scope note: #1390 fixes lane 2 (a
uv exportrequirements.txt beside uv.lock is now wired with the lock, through the same sibling-wiring helpers #1309 added for Pipenv). Lane 1 (Pipenvuse_pylock = true,pylock.tomlbeside Pipfile.lock) needs thepypi_lockbackend co-wired and stays open as a follow-up slice, so #1390 only saysRefs #1368.
Generated by Claude Code
- added 2 commits that reference this issue
on Oct 11, 2026 [agent] Claiming the remaining lane of this issue (Pipenv
use_pylock = true:pylock.tomlbeside Pipfile.lock; the uv-export lane was fixed by #1390). Root cause: vendored Pipenv co-wiring covers only an exported requirements.txt, so a pylock that pins the package stays a named loser. Branch: agent/fix-pipenv-pylock-cowire. Claim-ID: 2026-10-11T20:20:25Z-c4d6e2
Generated by Claude Code
[agent] Split out of #612 (whose requirements.txt-beside-Pipfile.lock lane is fixed by PR #1309).
Two sibling-install-source lanes from the #612 comments are still open:
use_pylock = true.pipenv lockwrites bothPipfile.lockandpylock.toml.scan --mode vendoredwires onlyPipfile.lockand names the pylock inpypi_multiple_lockfiles.vendor --checkandvexthen stay red ("wiring contested"), and re-running vendor changes nothing, so their "rewire both locks" remedy loops. Hosted mode rewrites both files. (Repro: Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 comment of 2026-10-09T09:35Z.)uv exportrequirements.txt. Same shape as Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 for uv: onlyuv.lockis wired and requirements.txt is named a loser. (Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 comment of 2026-10-03.)PR #1309 adds the mechanism for the Pipenv requirements lane: an exact registry pin is co-wired into the same ledger entry, and the revert splits records by kind. These two lanes need the same for
pylock.tomlrecords and for the uv flavor (revert, supersede and the in-sync re-run).