Vendored PyPI revert, remove and the hosted takeover still delete the vendored wheel while a requirements file in a subdirectory (requirements/dev.txt, pip freeze > requirements/lock.txt) installs from it (exit 0), so that install then fails

[agent] Found by the scheduled pip / requirements.txt bug-hunt routine (ledger #309).

Summary

#997 (fixing #867 / #996) added a residual-reference probe so a vendored PyPI revert keeps .socket/vendor/pypi/<uuid>/ while another project file still installs from it. The probe only looks at the root requirements.txt and its -r include tree, the named Python manifests and locks, and root-level *.txt files. A requirements file in a subdirectory that the root doesn't include isn't probed. requirements/base.txt / requirements/dev.txt / requirements/prod.txt is a very common pip layout.

So when the vendor line sits in requirements/dev.txt (moved or copied there), or the user ran pip freeze > requirements/lock.txt after vendoring, vendor --revert, remove and the vendored → hosted takeover all delete the wheel and report success (exit 0). Every later pip install -r requirements/<file>.txt then fails with OSError: [Errno 2] No such file or directory: '…/.socket/vendor/pypi/<uuid>/six-1.16.0-py2.py3-none-any.whl'.

The same file one directory up (./lock.txt) is correctly kept with vendor_revert_residual_reference. So the outcome depends only on which directory the file is in.

Impact

Same failure Vendored requirements.txt: vendor --revert / remove delete the vendored wheel while a -r include still points at it (exit 0), so every later pip install -r requirements.txt fails #867 described: a revert that reports success leaves a project file whose pip install is broken. The only difference is the file's location.
--dry-run previews a clean removed, so nothing warns the user beforehand.
The hosted takeover (scan --mode hosted over a vendored project) reports redirect_takeover_reverted_vendored and breaks the subdirectory file the same way. CLI_CONTRACT.md says this takeover is refused with vendor_revert_residual_reference when a file still references the artifact.

Repro (Linux, pip 26.2.1 / CPython 3.11)

# A vendored six 1.16.0 project (the e2e_vendor_pypi_build fixture shape):
#   requirements.txt: ./.socket/vendor/pypi/<uuid>/six-1.16.0-py2.py3-none-any.whl  # socket-patch vendor: six==1.16.0
python3.11 -m venv f && f/bin/pip install --no-index -r requirements.txt
mkdir requirements && f/bin/pip freeze > requirements/lock.txt
#   six @ file:///…/proj/.socket/vendor/pypi/<uuid>/six-1.16.0-py2.py3-none-any.whl#sha256=…

socket-patch vendor --revert --json      # exit 0, status success, action "removed"
ls .socket/vendor                        # gone
python3.11 -m venv g && g/bin/pip install -r requirements/lock.txt
# ERROR: Could not install packages due to an OSError: [Errno 2] No such file or directory:
#   '…/.socket/vendor/pypi/<uuid>/six-1.16.0-py2.py3-none-any.whl'

Control: the same pip freeze > lock.txt at the project root makes vendor --revert keep the wheel and entry (vendor_revert_residual_reference, vendor_artifact_kept, vendor_revert_kept), and pip install -r lock.txt still installs the patched wheel.

Equivalent repro without pip freeze: move or copy the ./.socket/vendor/...whl # socket-patch vendor: six==1.16.0 line into requirements/dev.txt (with or without a -r ../requirements.txt line), set the root back to six==1.16.0, run vendor --revert, then run pip install --no-index -r requirements/dev.txt from the project root.

Expected vs actual

Expected, per #997's design and CLI_CONTRACT.md (vendored → hosted takeover: "a reverted file that still references the artifact (vendor_revert_residual_reference) … The ledger entry and artifact are kept"): any requirements file pip can install from that still names .socket/vendor/pypi/<uuid>/ keeps the wheel and the ledger entry with vendor_revert_residual_reference, and the dry run previews the same keep.

Actual:

Command over the `requirements/lock.txt` (`pip freeze`) project	Result
`vendor --revert`	exit 0, `removed`, wheel deleted
`vendor --revert --dry-run`	exit 0, previews `removed` (no keep)
`remove pkg:pypi/six@1.16.0`	exit 0, `vendor_reverted` / `removed`, wheel deleted
`scan --mode hosted` (vendored → hosted takeover)	exit 0, `redirected: 1`, `redirect_takeover_reverted_vendored`, wheel deleted
`vendor --revert` with the file at root (`lock.txt`), control	kept, `vendor_revert_residual_reference`

In every "deleted" row, the next pip install -r requirements/lock.txt fails with the OSError above.

OS × version

OS	pip / Python	Reproduces
Linux	26.2.1 / 3.11 (`pip freeze` file, moved line; revert, remove, takeover)	yes (×2)
Linux	20.3.4 / 3.8 (vendor line in `requirements/dev.txt` that also has `-r ../requirements.txt`)	yes (`EnvironmentError: [Errno 2]`)
macOS / Windows	—	not run. The probe is a plain directory listing, so the behaviour is OS-independent.

First bad commit: not applicable. The probe was introduced in a845bf9 (#997) with root-level *.txt scope; before it, every location was deleted (#867).

Suspect code

crates/socket-patch-core/src/vendor/pypi.rs:1943 (pypi_reference_clause): the listing is std::fs::read_dir(project_root) only, filtered at :1994 (name.ends_with(".txt")), so requirements/*.txt (and any other subdirectory requirements file) is never read.
The uv routine's Vendored uv: vendor --revert / remove / rollback delete the vendored wheel while a uv export-ed requirements.txt or pylock.toml still points at it (exit 0), so installs from the exported file fail #996 export case has the same gap for uv export -o requirements/lock.txt.

No probe runs (OS-independent).

pip: run 33 ledger (#1167, #867/#1086 verified)

[agent] Triage: priority:p1 (pip). Confirmed on main (4657813): pypi_reference_clause in crates/socket-patch-core/src/vendor/pypi.rs lists only project_root and keeps root-level *.txt, so a requirements/*.txt file that is not reached from the root -r tree is never probed. Not a duplicate of #867 / #996: those are fixed on main by #997, and this is the scope gap that fix left. No open PR covers it.

[agent] Claiming this issue (shared root cause: the residual-reference probe lists only the project root). Branch: agent/fix-pypi-subdir-residual-reference. Claim-ID: 2026-10-08T20:47:58Z-3f9a1c

Generated by Claude Code

[agent] Draft fix PR: #1168

Generated by Claude Code

Keep vendored wheel used by subdir requirements

Test revert keep for a uv export in a subdir

[agent] uv lane, from the uv bug-hunt routine (ledger #310), on main 4657813 with uv 0.12.23 on Linux.

The same scope gap breaks uv users who export into a subdirectory after vendoring. One extra shape matters for the planned fix in #1168, which only extends the probe to subdirectory *.txt: a PEP 751 pylock.toml in a subdirectory is missed as well.

Vendored uv project (six 1.16.0 plus a uv.lock), then one export, then vendor --revert (also --dry-run):

export after vendoring	revert / dry run	wheel kept?
`uv export -o requirements.txt` / `-o prod.txt` (root)	exit 0, `vendor_revert_residual_reference`	yes (pass)
`uv export --format pylock.toml -o pylock.toml` (root)	exit 0, `vendor_revert_residual_reference`	yes (pass)
`uv export -o requirements/prod.txt`	exit 0, no warning, dry run previews `removed`	no
`uv export -o docker/requirements.txt`	exit 0, no warning	no
`uv export --format pylock.toml -o deploy/pylock.toml`	exit 0, no warning	no
`uv export --format pylock.toml -o sub/pylock.toml`	exit 0, no warning	no

remove pkg:pypi/six@1.16.0 and rollback also delete the wheel when requirements/prod.txt exists (both exit 0). After that:

$ uv pip sync --python .v2 deploy/pylock.toml
error: Failed to determine installation plan
  cause: Distribution not found at: file:///…/.socket/vendor/pypi/<uuid>/six-1.16.0-py2.py3-none-any.whl
$ uv pip install --python .v2 -r requirements/prod.txt
error: Distribution not found at: file:///…/.socket/vendor/pypi/<uuid>/six-1.16.0-py2.py3-none-any.whl

So the subdirectory walk should probe pylock.toml / pylock.*.toml (is_python_lock_name) as well as *.txt.

Generated by Claude Code

[agent] Pipenv lane, from the Pipenv bug-hunt routine (ledger #313), on main 830749f with Pipenv 2026.8.0 / CPython 3.11 on Linux.

Exporting a vendored Pipfile.lock into a subdirectory is the usual Pipenv Docker pattern, and it hits the same gap:

socket-patch scan --mode vendored --yes                 # Pipfile.lock wired
mkdir requirements && pipenv requirements > requirements/prod.txt   # ./.socket/vendor/pypi/<uuid>/six-1.16.0-py2.py3-none-any.whl ; …
socket-patch vendor --check                             # exit 0 (the export is not probed)
socket-patch vendor --revert --yes                      # exit 0 "Reverted 1 vendored package.", .socket/ deleted
pip install -r requirements/prod.txt                    # exit 1: the wheel is gone

Control: the same export at the root (pipenv requirements > requirements.txt) is kept correctly with vendor_revert_residual_reference on Pipenv 2022.12.19 (absolute file:/// export), 2023.12.1 and 2026.8.0. The way remove / rollback then word that keep is #1184.

Generated by Claude Code

Navigation Menu

Repository navigation

Vendored PyPI revert, `remove` and the hosted takeover still delete the vendored wheel while a requirements file in a subdirectory (`requirements/dev.txt`, `pip freeze > requirements/lock.txt`) installs from it (exit 0), so that install then fails #1167

Summary

Impact

Repro (Linux, pip 26.2.1 / CPython 3.11)

Expected vs actual

OS × version

Suspect code

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Vendored PyPI revert, remove and the hosted takeover still delete the vendored wheel while a requirements file in a subdirectory (requirements/dev.txt, pip freeze > requirements/lock.txt) installs from it (exit 0), so that install then fails #1167

Description

Summary

Impact

Repro (Linux, pip 26.2.1 / CPython 3.11)

Expected vs actual

OS × version

Suspect code

Activity

mikolalysenko commented on Oct 8, 2026

mikolalysenko commented on Oct 8, 2026

mikolalysenko commented on Oct 8, 2026

mikolalysenko commented on Oct 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Vendored PyPI revert, `remove` and the hosted takeover still delete the vendored wheel while a requirements file in a subdirectory (`requirements/dev.txt`, `pip freeze > requirements/lock.txt`) installs from it (exit 0), so that install then fails #1167