GeezerVison

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

Fixes #674

Summary

After a hosted→vendored takeover of two or more Hatch packages, rollback, remove and vendor --revert used to leave allow-direct-references = true (plus empty [tool] / [tool.hatch] tables) behind. That silently turned off Hatchling's direct-reference guard and kept the pyproject dirty. With this change the pyproject comes back byte-exact.

Root cause

The takeover in commands/vendor.rs calls restore_upstream with one hosted pin per candidate inside the vendoring loop. When the first Hatch package is vendored, the other packages' hosted direct references are still live, and so is the permission hosted mode added for them. The vendored hatch_permission record snapshotted that state as its original. Later packages clone the same record. So once the last reference was unwired, the revert "restored" a permission the user never had.

Fix

• vendor/pypi_hatch.rs::wire: a new permission record now checks the project for a direct reference the vendored ledger doesn't own (anything that isn't a {root:uri}/.socket/vendor/… reference). If there is one, the permission it finds is held for those references, so the record's original is the document with that permission removed, along with any tables that leaves empty. The hosted unwind already applies this rule: it drops the permission once no project direct reference is left. Because the decision is made once when the record is created, every package that clones the record inherits it, whatever the revert order.
• utils/hatch.rs: drop_direct_reference_permission and permission_keys now live here. The hosted unwind (redirect/upstream/pypi.rs) and the vendored ledger share them, so both lanes produce the same bytes.
• revert is unchanged. A permission the user set themselves (with no non-vendored direct reference live at wiring time) is still recorded and restored verbatim.

I didn't restructure the generic per-pin takeover loop. It carries many per-candidate refusal gates, and the pnpm (#636) and uv (#670) leftovers have different mechanisms; #672 covers those.

Tests (red → green)

Per-issue checklist:

• Hatch hosted→vendored takeover with two or more patches leaves allow-direct-references = true (plus empty [tool]/[tool.hatch] tables) behind after rollback or remove, disabling Hatchling's direct-reference guard #674: hosted→vendored with 2 patches, then rollback / remove / vendor --revert (all three go through pypi_hatch::revert) → byte-exact pyproject. Covered by the first two tests above.

Local validation

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo test -p socket-patch-core --lib -- pypi_hatch hatch upstream: 87 passed.
• cargo test --workspace --all-features --no-fail-fast: everything passes except 12 tests that simulate write or removal failures with chmod / read-only dirs. The sandbox runs as root, which bypasses those permissions. None of them touch Hatch code. CI runs unprivileged.
• SOCKET_PATCH_HATCH_E2E_REQUIRED=1 SOCKET_PATCH_HATCH_E2E_VERSION=1.18.1 cargo test -p socket-patch-cli --all-features --test e2e_vex_build -- hatch:: --ignored: 4 passed.
• rustfmt --check is clean on the touched files. Note that cargo fmt --all -- --check fails on main itself (about 130 files, from 045d7ec), and CI doesn't run rustfmt. I kept those unrelated reformats out of this PR; only one existing line in utils/hatch.rs was reflowed.

Behaviour note

If a user had both their own direct reference and allow-direct-references = true before vendoring, the permission is kept as long as any project direct reference remains. It is dropped only once none is left, which is what hosted mode already does.

🤖 Generated with Claude Code

Generated by Claude Code