You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit b41b9d3
Browse filesBrowse the repository at this point in the historyBrowse files
* Start fix for #912, #1122
Assisted-by: Claude Code:claude-opus-5-5
* Stop wiring pylocks that Pipenv installs from
A pylock.toml (or pylock.<name>.toml) beside a Pipfile is read by
Pipenv, not by a PEP 751 installer, and every pylock code path treated
it as installer-neutral:
- Vendored scans of a `use_pylock = true` project (Pipfile, Pipfile.lock
and pylock.toml) wired only pylock.toml. Pipenv installs from
Pipfile.lock when both exist, so every `pipenv sync` and
`install --deploy` got the unpatched release after a "success" run
(#1122). The router now wires Pipfile.lock and names the pylock in
the pypi_multiple_lockfiles warning.
- Hosted and vendored scans of a pylock-only Pipenv checkout wrote an
`archive` entry that Pipenv's pylock reader drops, so `pipenv sync`
installed the upstream release while the scan reported success, and
vendored VEX attested not_affected (#912). Both modes now refuse with
a `pipenv lock` pointer (redirect_pipenv_pylock_unsupported /
pypi_pipenv_pylock_unsupported), and VEX discovery no longer trusts a
Socket reference in such a pylock.
The rule lives in one predicate, utils::python_lock::pipenv_reads_pylock,
shared by the hosted rewriter, the vendored router and VEX discovery.
Assisted-by: Claude Code:claude-opus-5-5
* Test Pipenv pylock projects with real Pipenv
Adds a real-Pipenv 2026 e2e (part of the existing e2e_vex_build
pipenv:: legs) for a `[pipenv] use_pylock = true` project:
- with Pipfile.lock and pylock.toml, vendored mode wires Pipfile.lock
and a fresh `pipenv install --deploy` gets the patched release
(#1122);
- the pylock-only checkout is refused in hosted and vendored mode and
the pylock is left untouched (#912).
Documents both cases in the Pipenv compatibility table.
Assisted-by: Claude Code:claude-opus-5-5
* Let a governing tool lock outrank a stray Pipfile
A Pipfile left beside a governing uv.lock, poetry.lock or pdm.lock
does not make Pipenv the installer, but the hosted pylock rewriter and
VEX discovery still treated the pylock as Pipenv's. The hosted refusal
then marked the patch refused for every Python lock, so a successful
uv.lock pin was reported as not redirected and dropped from VEX.
pipenv_reads_pylock now applies the same tool-lock precedence the
vendored router already used, so all three call sites agree.
Assisted-by: Claude Code:claude-opus-5-5
* Serialize real-PM tool venv bootstraps
bootstrap_tool checks for a healthy tool venv and then creates it, with
no lock in between. The Pipenv e2e suite now has two tests, and libtest
runs them in parallel. On a cold tools cache both miss the probe and
race `uv venv` on the same pipenv-<version> directory, so one fails with
"a virtual environment already exists". This reproduced in CI and 5/5
times locally from an empty tools root. A process-wide lock around the
check-and-create fixes it; warm-cache runs only pay for a --version probe.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PzAvnBX6HySvR6zXsFtdy7
---------
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments