GeezerVison

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

Fixes #638

Summary

A scan --mode hosted --json over a pip project whose venv holds a
patched package, but which has no root requirements.txt or Python lock,
exited 0 with an empty warnings list. The only machine-readable signal
was the per-purl redirect_unconfirmed row (#1029). Every other
ecosystem reports this case with a stable code
(redirect_npm_no_lockfile, redirect_composer_no_lockfile,
redirect_gem_no_gemfile, ...). PyPI now reports
redirect_pypi_no_lockfile, once per run.

Layouts covered (the issue's matrix and its uv comment):

• only requirements-dev.txt
• only requirements/base.txt
• no requirements file at all
• a pyproject.toml project whose uv.lock is not committed (the
  detail tells the user to run uv lock / poetry lock / pdm lock)

Root cause

Each PyPI hosted rewriter (pdm, Pipenv, requirements, Hatch, uv/pylock,
Poetry) acts only on the file it owns and returns silently when that file
is absent. No PyPI-level check covered "none of them is present", unlike
the npm branch in patch/redirect/mod.rs or composer's
formats/composer/hosted.rs.

Fix

warn_no_pypi_wiring runs last in the PyPI rewriter group
(patch/redirect/mod.rs). When a pypi patch reaches the lane and the
project has no root requirements.txt, uv.lock / poetry.lock /
pdm.lock / Pipfile.lock, PEP 751 / PEP 723 lock, or Hatch
configuration, it pushes one warning. The warning names the files looked
for and says that other requirements files (such as requirements-dev.txt)
are not read. When any of those files is present, it owns the diagnostics
(e.g. redirect_requirements_entry_not_found) and no warning is added.
Patches withheld earlier (platform wheels #701, pdm/Pipenv refusals) don't
trigger it. Unreadable or undecodable candidate files already refuse the
project before the rewriters run, so they can't produce a misleading
"no lockfile".

CLI_CONTRACT.md lists the new code as an additive v5.0 redirect_*
warning. Wrappers (npm/, pypi/, gem/) don't name warning codes,
so they need no change.

Out of scope, as the issue says: the hosted exit status for an
unpinned patch is still 0 (the open #704 decision).

Tests

Red → green:

• Before the fix: cargo test -p socket-patch-core --lib pypi_no_lockfile
  gave 2 failed (every_lockless_layout_warns_once: "requirements-dev.txt
  only: []", pyproject_without_a_lock_names_the_lock_step), 2 passed
  (the negative cases).
• After the fix: 4 passed.

Local runs:

• cargo fmt --all -- --check: ok
• cargo clippy --workspace --all-features -- -D warnings: ok
• cargo test -p socket-patch-cli --all-features --test mode_migration_pypi:
  75 passed (the new test re-run on d0dc53c: passed)
• pypi_no_lockfile_tests on d0dc53c: 6 passed
• cargo test -p socket-patch-core --all-features --lib: 6998 passed and
  4 failed. All 4 failures depend on chmod making a directory unwritable
  (copy_tree::relax_loop_must_not_traverse_symlinked_root,
  vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry,
  pypi_poetry::wire_write_failure_maps_error_and_leaves_lock_untouched,
  pypi_requirements::wire_failure_rolls_back_already_written_files), so
  they can't pass in this container, which runs as root (uid 0). None of
  them is touched by this diff.
• A full cargo test --workspace --all-features ran out of disk in this
  session's container (about 20G of build cache). CI runs the whole
  workspace.

/code-review high

Fixed in d0dc53c:

• The remedy names the project's own lock step: pipenv lock for a
  Pipfile, and uv lock / poetry lock / pdm lock when pyproject
  names that tool (a [tool.*] table or its build backend). A plain
  pyproject gets both a root requirements.txt pin and the lock commands.
  Tested by the_remedy_names_the_projects_own_lock_step.
• The detail lists every silencing input (pylock..toml, PEP 723
  script lock, Hatch) and says "readable", because on disk an unreadable
  file is read as absent (the_detail_names_every_input_looked_for).
• The presence check matches root keys only, like the rewriters it
  stands in for.

Not changed:

• The presence list could drift from the rewriters' inputs. It reuses
  the shared governing_locks / python_lock / hatch predicates the
  rewriters themselves use. Having each rewriter report "saw an input"
  would touch six rewriters for a single warning. The suppression test
  covers every input, so a new input that isn't added here fails there
  only if a test for it is added; flagged here for review.
• A second is_hatch TOML parse. It runs only on the lockless path,
  which is once per run and has nothing else to do, so it isn't worth
  threading state between rewriters.

Generated by Claude Code