Skip to content

Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses #701

Closed
#984
Closed
Hosted uv scan silently wires a platform-specific patched wheel (cp311 manylinux) into a universal uv.lock, so uv sync --locked fails on every other Python version, macOS and Windows, and rollback then refuses#701
#984
Labels
agent:triagedbugSomething isn't workingbughuntFound by a scheduled package-manager bug-hunt agentpm:uvuvpriority:p1

Description

@mikolalysenko
Mikola Lysenko (mikolalysenko)
opened on Oct 3, 2026

[agent] Found by the scheduled uv bug-hunt routine (ledger #310).

Summary

When the patch service grants a platform-specific wheel for a pypi patch (here MarkupSafe-2.1.5-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl), hosted scan --mode hosted on a uv project rewrites [tool.uv.sources] and uv.lock so the package resolves only from that one wheel. It reports success with no platform warning (only the usual redirect_pypi_stale_install). uv.lock is a universal lock (requires-python = ">=3.9"), and before the rewrite it carried every MarkupSafe wheel. After the rewrite:

  • uv lock --check passes, and uv sync --locked works on the scanning machine (CPython 3.11, linux x86_64).
  • uv sync --locked on CPython 3.12 (same machine) fails: can't be installed because the binary distribution is incompatible with the current platform … only has wheels with the following Python ABI tag: cp311.
  • The same happens for --python-platform x86_64-apple-darwin, aarch64-apple-darwin and x86_64-pc-windows-msvc.
  • rollback then refuses (the release ships platform- or interpreter-specific wheels, and which of them uv kept … is not derivable; restore it from version control instead). That refusal is documented, so the only way back is git checkout.

The vendored path already handles this case: crates/socket-patch-core/src/vendor/pypi.rs:1139 emits vendor_platform_locked ("uv.lock now resolves it from this single-platform wheel only"). Hosted gem has a fail-closed guard for the same problem (redirect_gem_platform_unsupported, crates/socket-patch-core/src/patch/redirect/mod.rs:5533). Hosted pypi has neither a warning nor a refusal. The PEP 751 lane is affected too: a uv export --format pylock.toml pylock gets archive = { url = ".../MarkupSafe-2.1.5-cp311-cp311-manylinux…whl" }, also with no warning.

Impact

A team that runs hosted scan on a dev box or a single CI image commits a lock that breaks uv sync --locked for every teammate and CI job on another OS, architecture or Python minor version. Nothing in the scan output warns about it, and hosted rollback can't undo it.

Repro (Linux, real uv; local mock patch service)

The mock answers POST /v0/orgs/acme/patches/{batch,package}, GET …/by-package/… and GET …/view/<uuid>, and serves a deterministic patched copy of the real PyPI wheel MarkupSafe-2.1.5-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl (one marker line appended to markupsafe/__init__.py, RECORD regenerated), with SRI sha512 and hex sha256 integrity.

mkdir app && cd app
cat > pyproject.toml <<'EOF'
[project]
name = "app"
version = "1.0.0"
requires-python = ">=3.9"
dependencies = ["markupsafe==2.1.5", "packaging==24.1"]
EOF
uv lock && uv sync -p python3.11
socket-patch scan --mode hosted --json --yes --cwd . \
  --api-url http://127.0.0.1:8765 --api-token fake --org acme --patch-server-url http://127.0.0.1:8765
#  -> status success, redirected 1, warnings: [redirect_pypi_stale_install] only
uv lock --check                                   # ok
uv sync --locked -p python3.11                    # ok, patched
rm -rf .venv && uv sync --locked -p python3.12    # error: ... only has wheels with the following Python ABI tag: `cp311`
uv sync --locked -p 3.11 --python-platform x86_64-pc-windows-msvc   # error: ... incompatible with the current platform
socket-patch rollback --json --yes --cwd . ...    # partial_failure: "release ships platform- or interpreter-specific wheels ... restore it from version control"

The original (pre-scan) lock syncs fine with -p python3.12 and --python-platform x86_64-pc-windows-msvc.

Expected vs actual

  • Expected: hosted scan either refuses to redirect a uv lock (or pylock) to a single platform/ABI-tagged wheel when the lock is universal, like hosted gem's redirect_gem_platform_unsupported, or at least warns as vendored mode does (vendor_platform_locked). CLI_CONTRACT.md (rollback section, line 853) already treats "a release that has a wheel that is not pure Python 3" as a case hosted mode can't round-trip. A scan that creates a state its own rollback refuses, without telling the user, contradicts that.
  • Actual: silent success. The lock becomes cp311 + manylinux x86_64 only.

Matrix (Linux sandbox; macOS / Windows via uv's --python-platform resolver, not native runners)

uv scan warns? sync py3.11 linux sync py3.12 sync macOS x86_64 / arm64 sync Windows x64 rollback
0.5.31 no ok, patched fail – – –
0.8.17 no ok, patched fail – – refused (documented)
0.12.22 (latest) no ok, patched fail fail fail –

Main 045d7ec (CLI 4.0.0). Reproduced on three fresh projects (six or packaging as the sibling). Not bisected: the hosted uv rewriter has never had a platform check.

Suspect code

  • crates/socket-patch-core/src/patch/redirect/mod.rs:4638 (rewrite_uv_lock): ArtifactSource::Url(&dep.artifact_url) is planned and rewritten without inspecting the wheel filename's tags. Compare crates/socket-patch-core/src/vendor/pypi.rs:1139 (platform_locked → vendor_platform_locked) and wheel_filename_from_url in crates/socket-patch-core/src/api/client.rs:357.

Activity

  1. Mikola Lysenko (mikolalysenko)
    added
    bugSomething isn't working
    bughuntFound by a scheduled package-manager bug-hunt agent
    pm:uvuv
    on Oct 3, 2026
  2. Mikola Lysenko (mikolalysenko)
    added a commit that references this issue on Oct 3, 2026

    uv: run 12 ledger (#701)

    59b3e95
  3. Mikola Lysenko (mikolalysenko)
    added
    agent:triaged
    priority:p1
    on Oct 3, 2026

  4. mikolalysenko commented on Oct 3, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 3, 2026
    CollaboratorAuthor

    [agent] Triaged as priority:p1 (uv / PyPI family). Not a duplicate: no other open or closed issue covers hosted uv/pylock wiring of a platform-tagged wheel, and no open PR touches it. Confirmed on main (f6b7fb9): rewrite_uv_lock in crates/socket-patch-core/src/patch/redirect/mod.rs plans ArtifactSource::Url without looking at the wheel tags, while vendored mode's platform_locked check (vendor/pypi.rs, vendor_platform_locked) already parses them. Likely fix: reuse the vendored tag parse in the hosted uv/pylock planner and fail closed (or warn) on a universal lock.

    Generated by Claude Code

  5. mikolalysenko commented on Oct 4, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 4, 2026
    CollaboratorAuthor

    [agent] Two more uv lanes hit the same missing platform check (scheduled uv bug-hunt, ledger #310). Main 045d7ec, Linux, real uv, and the same local mock that serves the patched MarkupSafe-2.1.5-cp311-cp311-manylinux_2_17_x86_64.manylinux2014_x86_64.whl.

    1. Hosted requirements lane, uv pip compile --universal. The file is explicitly universal (its header names --universal). Before the scan it carried all 60 MarkupSafe hashes. Hosted scan replaces that entry with markupsafe @ http://…/MarkupSafe-2.1.5-cp311-cp311-manylinux…whl --hash=sha256:…. It reports status: success with no warning error code at all.

    printf 'MarkupSafe==2.1.5\nidna==3.7\n' > requirements.in
uv pip compile --universal --generate-hashes requirements.in -o requirements.txt
uv venv -p 3.11 && uv pip sync requirements.txt
socket-patch scan --mode hosted --json --yes --api-url $M --api-token fake --org acme --patch-server-url $M
uv venv -p 3.12 v12 && VIRTUAL_ENV=v12 uv pip sync requirements.txt
#  Caused by: A URL dependency is incompatible with the current platform: …cp311-cp311-manylinux…whl
#  hint: The wheel is compatible with CPython 3.11 (`cp311`), but you're using CPython 3.12 (`cp312`)
uv pip sync requirements.txt --python-platform x86_64-apple-darwin --target t   # same, "you're on macOS"
    uv scan warns? uv pip sync py3.11 py3.10 / py3.12 macOS (--python-platform)
    0.5.31 no ok fail –
    0.8.17 no ok fail (×2) fail
    0.12.23 no ok fail –

    Unlike the uv.lock lane, hosted rollback restores this requirements.txt byte for byte (when an unpatched sibling such as idna is present). So it can be recovered, but the scan still breaks every other interpreter in the meantime without saying so.

    2. PEP 723 script lock (uv lock --script), 0.8.17. The script gains # tool.uv.sources.markupsafe = { url = "…cp311-cp311-manylinux…whl" }, and tool.py.lock is narrowed to that wheel. There's no warning. uv run -p 3.11 --frozen --script tool.py prints 1, and uv run -p 3.12 --frozen --script tool.py fails with the binary distribution is incompatible with the current platform.

    So a fix in rewrite_uv_lock alone won't cover it. The requirements writer and the script-lock path need the same wheel-tag check, or the same vendor_platform_locked-style warning.

    Generated by Claude Code

  6. Mikola Lysenko (mikolalysenko)
    added a commit that references this issue on Oct 4, 2026

    uv: run 14 ledger (#742, #701 comment, pip handover)

    8567e9e

  7. mikolalysenko commented on Oct 6, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 6, 2026
    CollaboratorAuthor

    [agent] Shares root cause with #932: the hosted PyPI redirect never inspects the granted wheel's platform/ABI tags, in any of its lock writers (uv.lock, pylock, requirements, PEP 723 script locks, and Pipfile.lock in #932). Will be fixed together, with one check at the shared PyPI rewriter dispatch in patch/redirect/mod.rs.

    Generated by Claude Code

  8. mikolalysenko commented on Oct 7, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 7, 2026
    CollaboratorAuthor

    [agent] Claiming this issue (with #932; shared root cause: the hosted PyPI redirect never inspects the granted wheel's platform/ABI tags before narrowing a cross-platform lock). Branch: agent/fix-hosted-pypi-platform-wheel. Claim-ID: 2026-10-07T04:20:35Z-c338c4

    Generated by Claude Code

  9. Mikola Lysenko (mikolalysenko)
    added
    agent:claimed
    on Oct 7, 2026

  10. mikolalysenko commented on Oct 7, 2026

    @mikolalysenko
    Mikola Lysenko (mikolalysenko)
    on Oct 7, 2026
    CollaboratorAuthor

    [agent] Draft fix PR (also covers #932): #984

    Generated by Claude Code

  11. Mikola Lysenko (mikolalysenko)
    added 2 commits that reference this issue on Oct 7, 2026

    Stop hosted PyPI pinning platform-only wheels

    e50feee

    Keep vendored PyPI patch on a platform grant

    139fa65
  12. Mikola Lysenko (mikolalysenko)
    closed this as completedin #984on Oct 7, 2026
  13. Mikola Lysenko (mikolalysenko)
    removed
    agent:claimed
    on Oct 7, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    agent:triagedbugSomething isn't workingbughuntFound by a scheduled package-manager bug-hunt agentpm:uvuvpriority:p1

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions