Lock inventory and the vendored PyPI router disagree on which lock governs when poetry.lock or pdm.lock has no packages

[mikolalysenko]

[agent] Filed by the scheduled architecture audit routine (ecosystems and formats). Register: discussion #560 register.

Kind: bug. Source: new finding (follow-up to #1044 / E75); register E91.

Problem

#1044 moved the PyPI tool-lock order into one table, formats::governing_locks. The lock inventory still keeps its own copy of that order, and the two copies use different rules:

• Vendored router: vendor/pypi.rs#L269-L362 detect_pypi_flavor decides by presence. The first of uv.lock, poetry.lock, pdm.lock, Pipfile.lock that exists governs (pypi_governing_tool_lock, governing_locks.rs#L115-L124).``
• Lock inventory: lock_inventory/pypi.rs#L246-L300 inventory_pypi_locks_raw_in hand-codes uv → poetry → pdm → (Pipfile.lock + requirements.txt), keyed on whether a lock yielded entries. inventory_poetry_lock and inventory_pdm_lock return None for a lock with zero [[package]] blocks (#L415-L418, [`#L594-L597`](https://github.com/SocketDev/socket-patch/blob/ea097142389f6fa5bf202472cc1c1750a8464eef/crates/socket-patch-core/src/vendor/lock_inventory/pypi.rs#L594-L597)),`` and the inventory then falls through to requirements.txt. This is deliberate, and pinned by depless_poetry_lock_falls_through_to_requirements (lock_inventory/tests.rs:2722).

So with a package-less poetry.lock (Poetry writes package = [] for a project that declares no dependencies, for example one that uses Poetry only for packaging) beside a requirements.txt that pins the dependencies:

• The inventory, which feeds scan's candidate list and vendor's lockfile lookup, says requirements.txt resolves six==1.16.0.
• The vendored router wires poetry.lock. It then warns that "installs driven by requirements.txt will still install the UNPATCHED registry bytes" (the Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612 warning), and the Poetry backend refuses with pypi_poetry_lock_package_missing ("poetry.lock has no [[package]] entry for six; run poetry lock first"; pypi_poetry.rs#L213-L221).``

scan --mode vendored therefore offers a package that it then refuses to vendor, and the remedy it prints (poetry lock) does not help: re-locking an empty Poetry project produces the same empty lock. The same split applies to a package-less pdm.lock.

Proof by execution. I ran a throwaway unit test in vendor/pypi.rs twice on ea09714. The project had poetry.lock = package = [] plus a [metadata] section, a pyproject.toml with [tool.poetry], and requirements.txt = six==1.16.0:

INVENTORY: ["pkg:pypi/six@1.16.0"]
ROUTER: Ok(("Poetry", [VendorWarning { code: "pypi_multiple_lockfiles", detail: "multiple python lockfiles found; wiring `poetry.lock` — installs driven by requirements.txt will still install the UNPATCHED registry bytes" }]))

The output was identical on both runs.

Symptoms

None filed. This is the "lock inventory's own PyPI order" that #1044 left outside the table.

Impact

• Vendored PyPI refuses a package that scan reports as patchable, with a remedy that cannot work.
• This is the same class as Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612: two answers to "which PyPI lock governs".
• Low frequency (an empty tool lock beside a pinned requirements.txt), but every future change to PyPI precedence has to be made in two places.

Proposed change

• Add one predicate to formats::governing_locks that both callers use, for example pypi_governing(view) -> Option<&'static str>. It applies one rule for a tool lock that resolves no packages. The recommended rule is the inventory's: a package-less tool lock does not govern, so requirements.txt (or the next tool lock) does.
• inventory_pypi_locks_raw_in asks that predicate instead of its hand-coded if !uv_lock { poetry else pdm else … } chain. Delete the chain.
• detect_pypi_flavor asks the same predicate, so this project routes to Requirements, and the pypi_multiple_lockfiles warning no longer names poetry.lock as the governor.
• Keep the inventory's documented Pipfile.lock + requirements.txt union and the uv parse-success rule (an unparseable uv.lock falls through), stated once in the table's docs.

Size and scope

• formats/governing_locks.rs, vendor/lock_inventory/pypi.rs, vendor/pypi.rs (detect_pypi_flavor). Estimate under 150 production lines.
• Out of scope: hosted pdm_drives ignoring standalone pylock (a separate Decide which lockfile governs installs in one table #1044 deferral), and the takeover restore scope (Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612).

Acceptance criteria

• A regression test: the project above routes to PypiFlavor::Requirements, and inventory_project and detect_pypi_flavor agree on the governing source. Add the same for a package-less pdm.lock.
• depless_poetry_lock_falls_through_to_requirements and the formats::governing_locks tests stay green.
• The vendored PyPI e2e suites (e2e_vendor_pypi*, mode_migration_pypi) stay green.
• No other file in vendor/lock_inventory/ spells the PyPI tool-lock order.

Dependencies

• Decide whether a hosted patch is pinned through lockfile discovery alone #1058 edits lock_inventory/pypi.rs and Decide vendored-entry liveness through one discovery verdict #1050 edits vendor/pypi.rs. Rebase after them.
• Related: Vendored mode in a Pipenv project wires only Pipfile.lock and silently leaves a sibling requirements.txt unpatched, and the hosted → vendored takeover reverts that file's hosted pin to plain PyPI #612, E75 (Decide which lockfile governs installs in one table #1044).

---

Backlog review — 2026-10-08

Priority: P1 → P3. An empty tool lock beside requirements causes a false refusal, not a false security attestation. Narrow layout edge; retain the inventory/router fix.