GeezerVison

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

Fixes #479

Summary

Hatch 1.17+ locked environments (lock-envs = true, [tool.hatch.envs.<env>] locked = true) write a PEP 751 pylock.toml / pylock.<env>.toml that Hatch derives from pyproject and regenerates whenever the dependency hash changes. Both modes rewrote only that lock and reported success with no warnings:

• An existing Hatch env stayed unpatched, because pyproject was unchanged so Hatch didn't sync.
• A fresh env made Hatch regenerate the lock from pyproject, which threw the Socket URL away.
• Vendored skipped the documented "Vendored Hatch requires the pip installer" refusal.

Root cause

rewrite_hatch (patch/redirect/mod.rs) returned early whenever any is_python_lock_name file existed, and detect_pypi_flavor (vendor/pypi.rs, step 2) sent a pylock containing the package to the python-lock lane. Neither could tell a Hatch-derived lock from an independent one (uv export, pip lock).

Fix

• utils::hatch::is_hatch_lock(files, path) returns true for a pylock*.toml in a Hatch project (is_hatch) whose pyproject [tool.hatch] or hatch.toml locks environments (lock-envs = true, an env's locked = true or lock-filename).
• Hosted: rewrite_hatch no longer stops at a Hatch-derived pylock. It wires the Hatch declarations (pyproject / hatch.toml) and warns redirect_hatch_lock_regenerated (run hatch dep lock). The python-lock lane still rewrites the lock as well, so lockfile discovery sees one consistent wiring; when only pyproject was wired, the attribution gate (redirect_unattributable) withheld the dep. Hatch then regenerates the lock from the wired pyproject.
• Vendored: detect_pypi_flavor leaves Hatch-derived pylocks out of the standalone-lock lane, so the project routes to the Hatch flavor and its guards. That includes the uv-installer refusal locked environments hit.
• A pylock in a Hatch project without locked environments is still wired as a standalone lock (unchanged).
• docs/testing/hatch.md and the CLI_CONTRACT.md warning table are updated.

Tests (red → green)

Red was verified by short-circuiting is_hatch_lock to false. Hatch isn't installed locally, so the real-Hatch matrix from the issue wasn't re-run here.

Commands run

• cargo test -p socket-patch-core --lib: 6111 passed
• cargo test -p socket-patch-cli --test mode_migration_pypi --test in_process_get_hosted_ecosystems --test e2e_vendor_pypi_build --test in_process_rollback_hosted: 47 + 10 + 44 + 35 passed
• cargo clippy --workspace --all-features -- -D warnings: clean. cargo fmt --all -- --check: my files clean (the upstream/mod.rs diff is pre-existing on main)

🤖 Generated with Claude Code