GeezerVison

The World Wide Web, restored to 800 pixels of glory.

GeezerVison is showing github.com — Fix hosted Hatch ignoring uv sources (#673) by mikolalysenko · Pull Request #1706 · SocketDev/socket-patch

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.

Copy link

Copy Markdown

Collaborator

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

Fixes #673

What it fixes

Hosted Hatch scans could report redirected and exit 0 while every fresh Hatch environment still installed the unpatched wheel, or failed to install at all. This happened when a Hatch environment uses the uv installer and the project has a [tool.uv.sources] entry for the patched package.

Root cause

Hosted mode rewrites the [project] declaration to a direct reference (six @ <patch url>#sha256=…), but the Hatch planner (crates/socket-patch-core/src/utils/hatch.rs) never read [tool.uv.sources]. Hatch's uv installer runs uv pip install -e ., and uv resolves a project requirement through its tool.uv.sources entry instead of the direct reference. A url or path source installs the upstream wheel, and a git source fails with "conflicting URLs".

Change

utils/hatch.rs: when any Hatch environment uses the uv installer (installer = "uv" or a non-empty uv-path, in pyproject or hatch.toml, or a non-empty HATCH_ENV_TYPE_VIRTUAL_UV_PATH), a patched package with a non-index [tool.uv.sources] entry (url, path, git, workspace, empty array, or a marker array with any non-index member) can no longer be rewritten in [project].dependencies or optional-dependencies. The refusal happens before anything is written, like Hatch's own source tables. The hosted lane reports it as redirect_hatch_unsupported and leaves the dep unconfirmed, so the scan fails closed. Other packages in the same batch still rewrite.
Still rewritten, matching the issue's measured matrix: environment dependencies (Hatch passes them to uv as plain strings), index-only sources (the direct URL wins), and the pip installer (pip ignores the table).
docs/testing/hatch.md: documents the refusal.
Vendored mode is unchanged. It already refuses the uv installer outright.
npm/pypi/gem wrappers only dispatch to the binary, so they need no change.

Tests

Issue	Regression test	red → green
#673	`utils::hatch::tests::uv_sources_refuse_project_rewrites_under_the_uv_installer` (url / path / git / case-folded name / marker array × project deps / optional deps × `installer` / `uv-path` × pyproject / hatch.toml; plus the allowed shapes, the env-var switch, an empty array and a mixed batch)	fails on main, passes here
#673	`patch::redirect::hatch_tests::hatch_uv_source_leaves_the_dep_unconfirmed` (lane-level: no pyproject write, uuid unconfirmed, `redirect_hatch_unsupported`)	fails on main, passes here

Run locally:

cargo fmt --all -- --check: ok
cargo clippy --workspace --all-features -- -D warnings: ok
cargo test -p socket-patch-core --lib hatch: 64 passed. With the fix disabled, both new tests fail.
cargo test --workspace --all-features --no-fail-fast: 234 targets ok. 11 tests fail only in this container, and the same tests fail on main here. They are chmod-based write-failure tests, which can't fail while the container runs as root (in_process_redirect, repair, 4 core lib tests). The other two are e2e_bun_lockb tests, because the container has bun 1.4.4 instead of CI's version. None touch Hatch.
SOCKET_PATCH_HATCH_E2E_VERSION=1.18.1 cargo test -p socket-patch-cli --all-features --test e2e_vex_build hatch:: -- --ignored: 6 passed

/code-review high findings not fixed

Index sources are allowed through. The issue reporter measured six = { index = "internal" } with Hatch 1.18.1 + uv and the direct URL won ("pass"), so refusing would be a false refusal. The reviewer's claim is unmeasured.
uv workspace-root sources aren't read: only the project's own pyproject is checked. A Hatch project that is also a uv workspace member is a rare shape. Follow-up if it is reported.
no-sources isn't consulted. The refusal fails closed (agent mode still works), so this costs a false refusal, never an unpatched install.
A pyproject uv setting shadowed by a hatch.toml envs still counts as uv. This is the existing require_pip_installer_documents behavior shared with vendored mode, and it also fails closed.
VEX discovery crediting an already-written reference under a uv source is out of scope. The issue notes that vex already omits the package after inspecting the env.
Round recomputing the source set each round is a minor cost on a tiny TOML walk, so I left it.

Note

Medium Risk
Changes hosted Hatch redirect preconditions for uv + [tool.uv.sources]; behavior is fail-closed with new tests, but misclassification could block valid scans or leave edge cases (workspace-only sources) unhandled.

Overview
Fixes #673, where hosted Hatch scans could look successful while uv still installed the unpatched wheel when a Hatch env uses the uv installer and [tool.uv.sources] overrides the rewritten project pin.

The Hatch planner now reads [tool.uv.sources] when uv is active (installer = "uv", uv-path, or HATCH_ENV_TYPE_VIRTUAL_UV_PATH). For packages with a non-index source (url, path, git, mixed marker arrays, empty arrays), it refuses rewriting [project].dependencies and optional-dependencies before any write—same fail-closed pattern as other unsupported Hatch shapes. Hosted redirect leaves the dep unconfirmed, emits redirect_hatch_unsupported, and does not touch pyproject.toml. Environment dependency tables, index-only sources, the pip installer, and other packages in a batch still rewrite as before.

docs/testing/hatch.md documents this refusal. Regression coverage spans utils/hatch (matrix of source shapes and mixed batches) and redirect lane test hatch_uv_source_leaves_the_dep_unconfirmed.

^{Reviewed by Cursor Bugbot for commit 84d95a4. Configure here.}

Generated by Claude Code

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions


          Start fix for #673

632ba9d

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 24, 2026

Hosted Hatch scan exits 0 "redirected" when [tool.uv.sources] pins the patched package, but Hatch's uv installer obeys the source: url/path sources install the unpatched wheel and git sources break every install #673

Closed


          Refuse hosted Hatch pins shadowed by uv sources

4d216e3

When a Hatch environment uses the uv installer, uv resolves a project
dependency through the project's [tool.uv.sources] entry instead of
the direct reference hosted mode writes. A url or path source then
installs the unpatched wheel while the scan reports "redirected", and
a git source breaks every install with conflicting URLs.

Hosted Hatch now refuses such a pin before writing, as it already does
for Hatch's own source tables, and reports redirect_hatch_unsupported.
Environment dependencies, index-only sources and the pip installer
are unaffected and still rewrite.

Fixes #673

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 24, 2026

Swarm health manager log #1382

Open


          Also refuse uv sources under the uv env switch

84d95a4

HATCH_ENV_TYPE_VIRTUAL_UV_PATH switches Hatch to the uv installer with
no file setting, so a url or path source still shadowed the hosted
pin there. An empty source array is no longer treated as index-only.

Refs #673

Assisted-by: Claude Code:claude-opus-5-5

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026

Copy link

Copy Markdown

Collaborator Author

BugBot review

Generated by Claude Code

cursor[bot] reacted with thumbs up emoji

All reactions

👍 1 reaction

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) marked this pull request as ready for review

October 24, 2026 03:14

cursor Bot reviewed

Oct 24, 2026

View reviewed changes

cursor Bot left a comment

Copy link

Copy Markdown

There was a problem hiding this comment.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 84d95a4. Configure here.}

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

All reactions

Mikola Lysenko (mikolalysenko) added the Ready for review Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review label

Oct 24, 2026

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026

Copy link

Copy Markdown

Collaborator Author

Ready for review at 84d95a41da3ec23f57408b2b06cc2402bc280033.

CI: 38/38 non-skipped checks green (50 skipped), no main-wide failures.
Bugbot: reviewed this head, no findings; no open review threads.
Reviewer focus: the fail-closed refusal in utils/hatch.rs when uv is active and [tool.uv.sources] gives a package a non-index source (url/path/git/mixed/empty), and the redirect_hatch_unsupported path in patch/redirect/mod.rs.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026

Copy link

Copy Markdown

Collaborator Author

Labeled Ready for review by the burn-down agent.

Head: 84d95a41da3ec23f57408b2b06cc2402bc280033
CI: 38/38 non-skipped checks green (50 skipped), no main-wide failures
Bugbot: reviewed 84d95a4, no findings; no open review threads
Mergeable, no CHANGELOG.md changes
Reviewer focus: the uv-sources refusal in crates/socket-patch-core/src/utils/hatch.rs, and the HATCH_ENV_TYPE_VIRTUAL uv switch handling added in the last commit

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) enabled auto-merge

October 24, 2026 04:55

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026

Copy link

Copy Markdown

Collaborator Author

Final review brief

What it does. When a Hatch environment uses the uv installer, uv resolves a project requirement through [tool.uv.sources] and ignores the hosted direct reference. Hosted scans could therefore report redirected while uv still installed the unpatched wheel (#673). Now, a patched package that has a non-index uv source (url, path, git, workspace, an empty array, or a marker array with any non-index member) is refused in [project].dependencies and optional-dependencies before anything is written. The scan fails closed with redirect_hatch_unsupported, and other packages in the batch still rewrite.

Risk: low–medium. The change only adds refusals, so the worst case is a false refusal: the user is pointed to agent mode and never gets an unpatched install. The uv detection reuses the existing require_pip_installer_documents check, which vendored mode already relies on. Pip-installer projects, environment dependencies and index-only sources behave exactly as before.

Look here

hatch.rs:428-438: refuse_uv_source, which records the refusal on the target in the check pass, so the apply pass writes nothing for it
hatch.rs:445-480: uv_source_names, which decides uv detection and what counts as index-only
hatch.rs:587-590: reads HATCH_ENV_TYPE_VIRTUAL_UV_PATH from the process env
hatch.rs:383-401: applied only to the project tables, not to env dependencies
redirect/mod.rs:27172: lane-level test that checks the dep is left unconfirmed

Verified. I read the full diff and the check/apply round logic around it. A target refused in the check pass is skipped in the apply pass, so a partial write can't happen. cargo test -p socket-patch-core --lib hatch passes on the head (64/64). With uv_sources forced empty, both new tests fail (uv_sources_refuse_project_rewrites_under_the_uv_installer and hatch_uv_source_leaves_the_dep_unconfirmed), so they exercise the fix. CI is 38/38 green on the head (50 skipped by path filters), and ci-ok and clippy both pass. Bugbot reviewed the head with no findings. There are no review threads, and CHANGELOG.md is untouched. The PR body lists the known fail-closed gaps that weren't fixed (uv workspace-root sources, no-sources), and they are reasonable to leave.

Changes I made. None.

Open questions. None.

Auto-merge (squash) is armed: approving sends this PR straight to the merge queue.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 24, 2026

Stop late draft runs cancelling real PR CI #1708

Merged

Wenxin Jiang (Wenxin-Jiang) approved these changes

Oct 26, 2026

View reviewed changes

Mikola Lysenko (mikolalysenko) added this pull request to the merge queue

Oct 26, 2026

Tanmay Singla (Tanmay182003) approved these changes

Oct 26, 2026

View reviewed changes

github-merge-queue Bot removed this pull request from the merge queue due to failed status checks

Oct 26, 2026

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) commented Oct 26, 2026

Copy link

Copy Markdown

Collaborator Author

[agent] The merge queue removed this PR at 15:23 UTC with CI_FAILURE. The PR itself is fine. In queue run 40346721382, only e2e (ubuntu-latest, e2e_redirect_uv_build, 0.12.17) failed (plus ci-ok, which depends on it). Its only annotation is "The self-hosted runner lost communication with the server": the runner was lost mid-job (the same issue as #1660), not a failing test. That suite does not touch Hatch. The head 84d95a4 is unchanged, approved twice, and mergeable_state: clean.

Re-arming auto-merge from this session was not permitted, so it needs to be re-queued by hand: re-enable auto-merge or add it to the merge queue.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) mentioned this pull request

Oct 26, 2026

Depot runners lost mid-job evicted 2 merge-queue entries in 27h #1660

Open

Mikola Lysenko (mikolalysenko) added this pull request to the merge queue

Oct 26, 2026

Mikola Lysenko (mikolalysenko) commented Oct 26, 2026

Copy link

Copy Markdown

Collaborator Author

[final reviewer] Re-added to the merge queue at 15:50 UTC (squash auto-merge re-enabled). The 15:23 eviction was a lost self-hosted runner in e2e_redirect_uv_build, not this change. Head 84d95a4 is unchanged and approved, and ci-ok/clippy are green. This is its one re-add; if the queue drops it again for infra, the CI janitor and owner should look at the runner.

Generated by Claude Code

All reactions

Sorry, something went wrong.

Uh oh!

There was an error while loading. Please reload this page.

Merged via the queue into main with commit 73be80e

Oct 26, 2026

89 of 120 checks passed

Uh oh!

There was an error while loading. Please reload this page.

Mikola Lysenko (mikolalysenko) deleted the agent/fix-hatch-uv-sources-pin branch

October 26, 2026 16:17

This was referenced Oct 26, 2026

CI perf (settings): slow Depot 16-core hosts since 10-13 15:20 add ~1.5–2.5 min to the merge-queue critical path (~0.6k Linux job-min/day) #1512

Open

CI perf (settings): merge queue builds 5 entries at a time — a 13-PR burst took 100 min to drain on a 21-min CI run (~21 min per PR past the 5th) #1248

Open

CI performance dashboard #1182

Open

Reviewers

cursor[bot]

cursor[bot] left review comments

Wenxin Jiang (Wenxin-Jiang)

Wenxin-Jiang approved these changes

Tanmay Singla (Tanmay182003)

Tanmay182003 approved these changes

Uh oh!

There was an error while loading. Please reload this page.

Assignees

No one assigned

Labels

Ready for review

Agent-verified: mergeable, CI green, Bugbot clean — awaiting human review

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Uh oh!

There was an error while loading. Please reload this page.

4 participants

Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.

You are visitor 01402520 — GeezerVison does not store the pages you look up.
Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.

GeezerVison

Conversation

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

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

What it fixes

Root cause

Change

Tests

/code-review high findings not fixed

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026

Final review brief

Uh oh!

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 26, 2026

Uh oh!

Mikola Lysenko (mikolalysenko) commented Oct 26, 2026

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Mikola Lysenko (mikolalysenko) commented Oct 24, 2026 •

edited

Loading

Uh oh!

There was an error while loading. Please reload this page.