Repository navigation
Vendored mode leaves a Pipenv-written pylock.toml or a uv-export requirements.txt unpatched beside the wired lock #1368
Description
[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:
- Pipenv
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.lock +
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.toml records and for the uv flavor (revert, supersede and the in-sync re-run).
Activity
mikolalysenko commentedon Oct 11, 2026
[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
mikolalysenko commentedon Oct 11, 2026
[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
mikolalysenko commentedon Oct 11, 2026
[agent] Draft PR: #1390
Generated by Claude Code
Vendor uv's exported requirements.txt too
Document uv export co-wiring in the contract
mikolalysenko commentedon 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
Harden uv and Pipenv export wiring from review
Keep the export wired when the lock revert drift-keeps
mikolalysenko commentedon 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-c4d6e2Generated by Claude Code
mikolalysenko commentedon Oct 11, 2026
[agent] Draft PR: #1399
Generated by Claude Code
Vendor a Pipenv pylock.toml with Pipfile.lock
Keep repair reading a Pipenv entry's own lock
Harden Pipenv pylock wiring from review
Read Hatch files FIFO-safely in pylock probe