GeezerVison

LLM Description written by Claude Code:claude-opus-5-5

Fixes #333

Summary

A hosted scan never read the project's Pipfile, so every Pipenv project looked like it had an abandoned Pipfile.lock. When that lock pinned the package to the user's own wheel, another version or a VCS source, the scan still redirected a sibling requirements.txt, reported success, and warned that there was no Pipfile. Pipenv kept installing the unpatched package. A conflicting entry in a live Pipfile.lock now refuses the patch for the whole project, which is what the Pipenv rewriter already intended.

Root cause

The hosted planners read the files listed in REDIRECT_CANDIDATE_FILES, which come from the HOSTED rows of formats/registry.rs. Pipfile.lock has a row there, but Pipfile doesn't. The Pipenv rewriter (patch/redirect/pipenv.rs) tells a live lock from an abandoned one with files.contains_key("Pipfile"), and that check was never true in the disk flow or the in-memory flow.

Fix

• Pipfile is now a pypi HOSTED | PRESENCE_ONLY row in the format registry. It's read, never edited, and names no ecosystem for the symlink and unreadable refusals. Both the disk and in-memory hosted engines read it.
• read_candidate_files: a presence-only row that the in-memory host lists without usable content (a symlink, or an oversize or presence-only entry) is recorded as present (empty) instead of dropped. Without this, the in-memory engine would still treat a live lock as abandoned.
• The pinned candidate-list test lists Pipfile, and there's a CHANGELOG entry.

Tests (per issue)

• Hosted scan never sees the Pipfile, so a live Pipfile.lock conflict is treated as abandoned and a sibling requirements.txt is redirected anyway #333: in_process_redirect_pipenv::live_pipfile_lock_conflict_vetoes_the_requirements_redirect. Before the fix it fails: requirements.txt is rewritten to the hosted URL (left: "urllib3 @ https://patch.socket.dev/...", right: "urllib3==1.26.18\n..."). With the fix it passes, and requirements.txt, Pipfile.lock and Pipfile are left unchanged.
• Counterpart: abandoned_pipfile_lock_conflict_does_not_veto_the_requirements_redirect. With no Pipfile, the same conflict still lets requirements.txt be redirected. This was the intended behavior before and is unchanged.
• In-memory engine: hosted::engine::tests::the_pipfile_is_read_for_its_presence covers a disk read, a symlinked or content-less memory entry recorded as present, and an absent Pipfile that stays absent.
• formats::registry / engine::file_ecosystem: Pipfile names no ecosystem, so it never triggers a symlink or unreadable refusal.

Evidence

• CI on 6565fac: all 10 workflows green (CI, Pipenv, Poetry, PDM, npm, pnpm, Bun, vlt, Composer, Audit GHA). Bugbot found no issues on 6565fac.
• Local: cargo clippy --workspace --all-features -- -D warnings is clean. in_process_redirect_pipenv passes 6/6. The real-Pipenv 2026.8.0 e2e_vex_build pipenv:: --ignored passes.
• Local cargo test --workspace --all-features --no-fail-fast: only 14 chmod-based write-failure tests fail. They can't fail as intended in this sandbox, which runs as uid 0, and all pass in CI.
• cargo fmt --check already fails on main (CI doesn't run it). The new hunks are rustfmt-clean, and I didn't reformat any unrelated code.

Follow-ups

• Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328's vendored → hosted Pipenv row printed the wrong "no Pipfile beside the lock" clause. That clause is gone with this change, but the refusal itself has a separate cause (PyPI mode takeover) and stays tracked in Poetry hosted ⇄ vendored mode switch is refused, and blames a "user-authored" source that socket-patch wrote itself #328.

🤖 Generated with Claude Code

Generated by Claude Code