GeezerVison

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

Fixes #804

Summary

rollback, remove and the hosted → vendored takeover always refused a pylock.toml written by pip lock (pip 25.1+), so a hosted patch on such a project could be applied but never undone. They now restore the entry from PyPI, byte for byte.

Root cause

The hosted pylock upstream restore (crates/socket-patch-core/src/patch/redirect/upstream/uv.rs) only read a package's artifacts as uv writes them: inline wheels = [{ … }] / sdist = { … }. PEP 751 also allows the standard-table spelling that pip lock uses:

[[packages.wheels]]
name = "idna-3.7-py3-none-any.whl"
url = "https://files.pythonhosted.org/…"

[packages.wheels.hashes]
sha256 = "…"

artifact_tables and the shape probe in lock_shape used Item::as_array / inline tables only, so every pip sibling showed no artifacts, pylock_unindexed_registry returned None, and the restore refused with "no sibling registry package shows the registry and artifact fields this uv release records".

Fix

• artifact_tables reads both spellings through TableLike (inline arrays, [[packages.wheels]], inline or [packages.sdist]).
• Shape learns whether siblings use standard tables and a hashes sub-table. The restored entry is written in that spelling ([[packages.wheels]] + [packages.wheels.hashes], or [packages.sdist]).
• pip lock records only the artifact pip selected. For created-by = "pip" the restore writes only the release's wheel (or its sdist when it has no wheel). A release with several pure-Python wheels is refused, because which one pip picked depends on the interpreter that ran it.
• The refusal text no longer says "this uv release" (it also covers pip-written locks).
• CLI_CONTRACT.md documents the restore for both spellings.

Tests (red → green)

The hosted → vendored takeover goes through the same restore_upstream call, so the same tests cover it.

Commands run locally (head b33b0ed):

• cargo clippy --workspace --all-features -- -D warnings: clean.
• cargo fmt: the changed hunks are rustfmt-clean. main itself is not rustfmt-clean (many pre-existing diffs; CI has no fmt gate), so I didn't touch unrelated files.
• cargo test -p socket-patch-core --all-features: 5395 passed, 4 failed. The 4 failures are permission tests (copy_tree::relax_loop_must_not_traverse_symlinked_root, vlt_heal::an_unremovable_hidden_lock_keeps_every_store_entry, pypi_poetry::wire_write_failure_maps_error_and_leaves_lock_untouched, pypi_requirements::wire_failure_rolls_back_already_written_files). They fail the same way on main because the sandbox runs as root.
• cargo test -p socket-patch-cli --all-features --test e2e_vex_lockfile --test mode_migration_pypi --test hosted_memory_engine --test in_process_redirect_{pipenv,poetry,pdm}: 344 passed.
• e2e_redirect_uv_build hosted pylock lanes (pip-lock, export-pylock, compile-pylock) with real uv 0.8.17 + pip 26.2.1: all restore. I ran them through a local PyPI JSON relay, because this sandbox's Rust TLS client can't reach pypi.org directly. That relay was not committed.
• I couldn't run the full cargo test --workspace locally: building every test binary exceeds the sandbox's disk allowance. CI runs it.

Note: CI's host python3 likely has pip < 25.1, so the pip-lock e2e lane probably reports n/a there. The golden tests are the hermetic regression coverage.

Generated by Claude Code