[Mikola Lysenko (mikolalysenko)]

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

Refs #977

Summary

A vendored requirements.txt line could not be reverted once its
trailing # socket-patch vendor: comment was touched: respaced, a note
appended, or stripped by a formatter. pip reads the line the same and
vendor / vendor --check still called it wired, but vendor --revert,
remove and rollback drift-kept the wheel forever. With the comment
stripped, re-running vendor (the remedy the CLI prints) also appended a
second (transitive) line for the same wheel, and the next revert
stranded the user's line.

Root cause

The requirements flavor decided whether a line was "ours" two ways: the
forward paths keyed on the code part of the line, while revert (and the
superseding re-wire) needed the whole line, comment included, to equal
the recorded one. Separately, every reader named a vendored wheel line
only by its comment tag, so a line with the tag stripped was invisible
to vendor (hence the duplicate) and to the lockfile inventory.

Fix

• pair_recorded_lines (vendor/pypi_requirements.rs) pairs each
  recorded line with an exact copy first, then with a line whose code
  part (what pip reads) is unchanged. Records that wrote the same line
  then take their lines in file order, so identical lines never swap
  originals. Used by both revert_requirements and plan_rewire.
• vendor_lines and the lock inventory
  (lock_inventory/pypi.rs) name an untagged vendored wheel line by
  its wheel (the existing socket_reference_coords parser), so
  vendor reports it in sync instead of appending a duplicate.
• The vendor_artifact_kept hint now also names
  vendor_revert_line_drifted, the code this flavor emits.

Not in this PR (why Refs, not Fixes)

The issue also notes that vendor --revert exits 0 / success on a
drift-keep while remove exits 1, and that the human summary says
"lock entries were re-resolved". Both are shared by every vendored
ecosystem, so changing them is a cross-ecosystem contract decision, not
a requirements fix. The {:?} key formatting it mentions was already
fixed on main (#1608). #977 stays open for those.

Review notes (from /code-review high, not changed)

• An untagged .socket/vendor/pypi/... line now counts as wiring
  everywhere. A superseding vendor or a fresh wire now refuses
  (pypi_requirements_already_vendored) when such a line has no ledger
  record. Before, it went ahead and left that line pointing at a wheel
  dir the run deletes, or appended a second competing wheel line. The
  refusal is the safer outcome.
• A superseding re-wire rewrites an edited line to the standard shape,
  so a note the user appended is dropped. The rewire already replaces
  the whole line, and the note never affected pip.

Tests (red on main, green here)

Variant from #977	Unit test	E2E (real pip 24.0)
(a) respaced, (b) note appended, (c) stripped: revert restores the pin	revert_ignores_edits_to_the_vendor_comment (plain, hashed, transitive)	pip_requirements_revert_after_the_vendor_comment_is_edited
(c) re-vendor appends a duplicate line	an_edited_vendor_comment_is_still_in_sync	same e2e (re-vendor leaves the file alone)
superseding patch after an edit	rewire_and_revert_after_an_edited_vendor_comment
identical lines keep their own originals	revert_pairs_identical_vendor_lines_in_order_after_an_edit
exact or still-tagged line wins over a bare manual line	revert_prefers_an_edited_vendor_line_over_a_bare_copy,	revert_prefers_the_exact_vendor_line_over_a_bare_copy
scan inventory after the tag is stripped	vendored_requirements_lines_without_their_tag_stay_in_the_inventory

Before the fix the e2e fails at the first edit: vendor --revert
reports summary.removed: 0 with vendor_revert_line_drifted.

Commands run locally:

• cargo fmt --all -- --check: clean
• cargo clippy --workspace --all-features -- -D warnings: clean
• cargo test -p socket-patch-core --all-features --lib: 6929 passed,
  4 failed. All 4 are read-only permission tests that cannot fail as
  uid 0, which this container runs as. They fail the same way without
  this change.
• cargo test -p socket-patch-cli --all-features --test e2e_vendor_pypi_build -- --include-ignored pip_requirements: 2 passed
• The full cargo test --workspace did not fit the container's disk;
  CI runs it.

No wrapper (npm/, pypi/, gem/) changes: they only dispatch to
the binary.

https://claude.ai/code/session_011f9aeTBVmHpGBarPd1Gbh2

---

Generated by Claude Code

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

Stale Bugbot comment from a previous run.

[Mikola Lysenko (mikolalysenko)]

BugBot review

---

Generated by Claude Code

[cursor]

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 50be7f8. Configure here.}

[Mikola Lysenko (mikolalysenko)]

Ready for review (burn-down agent).

• Head: 50be7f887
• CI: 50/50 settled on the head (31 success, 19 skipped). Mergeable, no conflicts.
• Bugbot: reviewed 50be7f8 and found no new issues. Its one earlier thread (pypi_requirements.rs:362) is resolved.
• CHANGELOG.md is untouched.
• For the reviewer: before this fix, reverting a vendored requirements.txt line required the whole line to match, comment included, and the readers recognised vendor lines only by the comment tag. Editing the vendor comment therefore broke the revert (Vendored requirements.txt can't be reverted once the user touches the # socket-patch vendor: comment: vendor --revert drift-keeps forever (exit 0), and the suggested "re-vendor" remedy is a no-op or adds a duplicate line #977). The fix pairs edited lines with their originals and prefers the tagged line when there are several candidates.

---

Generated by Claude Code