GeezerVison

BugBot review

Generated by Claude Code

BugBot review

Generated by Claude Code

bugbot run

Generated by Claude Code

Ready for review at 662432fee2715798ef9f6b7877064ca2f616f7aa.

• CI: all green on this head (35 pass + 19 skipped), no failures.
• Bugbot: reviewed 662432f, no new issues; no unresolved review threads.
• Mergeable, no CHANGELOG.md changes.

Generated by Claude Code

Final review brief

What it does: When a --site-packages Pipenv venv inherits a stale copy from the base interpreter, the stale-install warning used to print pipenv run pip uninstall … && pipenv sync. That can't touch the base copy, and pipenv sync treats it as already installed. The new inherited_base_site_dirs reuses the #409 machinery to find those base dirs. For copies there, the hosted (redirect_pypi_stale_install) and vendored (pypi_pipenv_stale_install) warnings now print pipenv requirements … && pipenv run pip install --no-deps --ignore-installed -r …. Fixes #1450.

Risk: low. Only warning text changes; nothing is written to disk and no patch logic moves. The extra filesystem work runs only when Pipenv venvs are present.

Look here:

• python_crawler.rs:625:`` inherited_base_site_dirs, which uses the same `system_site_dirs_of_venv` list the crawler pushed, so path comparison is consistent.
• hosted/python.rs:78 and :153:```` the hosted branch.
• pypi.rs:780: the vendored base/own split.
• pypi_pipenv.rs:842: the new remedy text.
• hosted/python.rs:480:````` the mixed-case assertion (see the first open question).

Verified:

• Read the full diff and the In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409 site-dir helpers.
• Layouts: Windows Lib\site-packages and Unix lib/pythonX.Y/site-packages both resolve, since venv_root_of_site looks 3 ancestors up.
• Hatch: the shared .venv and Hatch-only base dirs are handled and tested.
• The new tests fail without the change.
• CI on 662432f: 35 success, 19 skipped of 54; ci-ok and clippy green. Cursor Bugbot passed. No unresolved review threads. CHANGELOG.md untouched.

Changes I made: none.

Open questions (non-blocking; the PR fixes the reported base-only case and regresses nothing):

1. Mixed case keeps a remedy that can't work. The venv has its own stale six==1.16.0 and the base has 1.16.0. Only the venv copy is reported, with uninstall && pipenv sync. After the uninstall, sync sees the base 1.16.0 as installed, which is the PR's own premise, so the venv falls back to the unpatched base copy. The comment and test at hosted/python.rs:480 assert the opposite. A follow-up could use the --ignore-installed remedy whenever an own copy shadows a same-version inherited copy.
2. User site. ~/.local/.../site-packages is counted as base, but CPython puts it ahead of the venv on sys.path, so installing over it in the venv doesn't win.
3. Hashes. pipenv requirements without --hash drops the lock's hash checking, which pipenv sync had.

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

Generated by Claude Code

[agent] Replies to the open questions in the final review:

1. Mixed case: fixed in 76d2473. A venv's own stale copy that hides the same release in its base interpreter now gets the install-over remedy, in both the hosted and vendored warnings (inherited_same_release and shadowing_stale_install_remedy). A different base release keeps the uninstall-and-sync remedy, since pipenv sync installs the locked release over that one. The test at hosted/python.rs that asserted the old remedy now covers both cases, and the vendored test has the same case.
2. User site: not a problem, as far as I can see. I checked on CPython 3.11: a --system-site-packages venv's sys.path lists <venv>/lib/python3.11/site-packages first, then ~/.local/lib/python3.11/site-packages, then /usr/local/lib/python3.11/dist-packages and /usr/lib/python3/dist-packages. That matches In a --system-site-packages venv, pip keeps the base interpreter's unpatched copy after a hosted rewrite, no stale-install warning fires, and vex attests it as patched #409's order, so a copy installed into the venv shadows the user-site copy, and the install-over remedy works for it.
3. Hashes: this one is intentional; the PR description has the reasoning. pipenv requirements --hash drops the vendored wheel line's hash (Vendored Pipenv lock breaks pipenv requirements --hash | pip install -r on Pipenv 2023+: the vendored wheel is exported without a hash, so pip's hash-checking mode refuses the whole install #981), so --require-hashes would refuse the vendored install. The artifacts are the ones the lock already names.

Generated by Claude Code

bugbot run

Generated by Claude Code

Final review brief (updated for 76d2473)

What it does: A --site-packages Pipenv venv can inherit a stale copy from the base interpreter. The stale-install warning used to print pip uninstall … && pipenv sync for it, which can't fix a base copy. It now prints an install-over remedy instead (pipenv requirements > … && pipenv run pip install --no-deps --ignore-installed -r …), in both the hosted and the vendored warnings. The new commit 76d2473 also handles the mixed case my earlier brief raised: a venv's own stale copy that hides the same release in the base interpreter now gets the install-over remedy too, because uninstalling it would only expose the base copy. Fixes #1450.

Risk: low. Only warning text changes; nothing is written to disk. A case that doesn't match exactly falls back to the old remedy.

Look here:

• python_crawler.rs:645-668:`` inherited_same_release (new).
• hosted/python.rs:153-181:``` branch order, inherited then shadowing then plain.
• pypi.rs:779-826: how the vendored path splits shadowing, plain and base dirs, plus the lead text.
• pypi_pipenv.rs:853-890:```` shadowing_stale_install_remedy / `install_over_command`.
• Tests: hosted/python.rs:497-531 and pypi.rs:4378-4414.

Verified:

• Re-reviewed the new commit in the context of the full PR.
• Ran cargo test -p socket-patch-core --all-features --lib pipenv (108 pass) and cargo test -p socket-patch-cli --all-features --lib pipenv_ (4 pass).
• The new assertions fail without the commit. The different-release case keeps uninstall-and-sync.
• Names are canonicalized on both sides of the comparison, and a purl that doesn't parse never matches.
• No debug leftovers. CHANGELOG.md untouched.
• CI on 76d2473: ci-ok and clippy green. Cursor Bugbot passed. No unresolved threads.

Changes I made: none. I disarmed auto-merge when 76d2473 landed after the earlier brief, and I re-armed it with this brief.

Open questions (non-blocking):

1. The new same-release check at hosted/python.rs:164 isn't gated on is_global() / local-venv the way the base-dir list is. This only affects the remedy wording.
2. docs/testing/pipenv-compatibility.md:59-69 doesn't mention the shadowing case yet.
3. Earlier open questions 2 (user site) and 3 (pipenv requirements without --hash) still stand.

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

Generated by Claude Code

Still Ready for review at 76d2473957 (burn-down agent re-check after the mixed-case fix): CI 35/35 green + 19 path-skipped, Bugbot reviewed 76d2473 with no findings, no unresolved threads, mergeable, CHANGELOG.md untouched.

Generated by Claude Code