Hosted and vendored uv scans wire a patched wheel into a project that sets no-binary / no-binary-package for that package, so every later uv sync fails ("marked as --no-binary but is itself a binary distribution") #1603

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

Summary

uv's no-binary = true and no-binary-package = ["<name>"] settings (in [tool.uv], uv.toml or a PEP 723 script's # [tool.uv]) forbid installing that package from a wheel. Every socket-patch PyPI artifact is a wheel: hosted mode pins the patch-server .whl URL, and vendored mode pins .socket/vendor/pypi/<uuid>/<name>-<ver>-py*-none-any.whl. When the patched package falls under one of these settings, scan --mode hosted and scan --mode vendored still wire it and exit 0 with no warning. After that, every install of the project fails:

error: Distribution `colorama==0.4.4 @ direct+http://…/colorama-0.4.4-py2.py3-none-any.whl` can't be installed because it is marked as `--no-binary` but is itself a binary distribution

This happens with uv sync --locked, uv sync --frozen, a plain uv sync and uv run --locked on a script. On uv 0.12+ uv lock --check also fails ("Failed to validate existing lockfile").

Impact

After a "successful" scan, CI and every fresh checkout can't install the project at all. The tool knows these keys exist: hosted rollback already refuses on any [tool.uv] no-binary* key (upstream/uv.rs:371), but nothing checks them at wire time. It's the same shape as #564 (no-sources), which was fixed by a pre-write refusal.

Repro

This uses the bughunt mock patch server (six / colorama patches; see the ledger) on 127.0.0.1:8765. Any free pure-Python patch shows the same thing.

mkdir nb && cd nb
cat > pyproject.toml <<'EOF'
[project]
name = "demo"
version = "0.1.0"
requires-python = ">=3.9"
dependencies = ["colorama==0.4.4", "attrs==24.2.0"]

[tool.uv]
no-binary-package = ["colorama"]
EOF
uv lock && uv sync                      # ok: colorama built from its sdist
socket-patch scan --mode hosted --json  # or --mode vendored   → exit 0, colorama wired
rm -rf .venv && uv sync --locked        # exit 1 (0.13.1) / 2 (≤0.8): "marked as --no-binary but is itself a binary distribution"
uv sync --frozen                        # same error

The same thing happens with no-binary = true, with no-binary-package in a uv.toml beside the project, and in a PEP 723 script (# [tool.uv] / # no-binary-package = ["colorama"], then uv lock --script s.py, scan, uv run --locked s.py exits 2).

Expected vs actual

• Expected: a refusal before any write, the way no-sources is refused with pypi_uv_no_sources (Hosted and vendored uv wiring ignore no-sources = true: scan and vendor report success, uv sync --locked then fails, and a plain uv sync reinstalls the unpatched wheel #564 / Fix uv wiring under no-sources = true (#564) #1434), because uv will never install a wheel for this package. Vendored mode's contract is that the next uv sync --locked installs the patched wheel, and hosted mode's is that the redirected URL is what the next install fetches. CLI_CONTRACT.md's hosted-restore rules already list "a uv lock whose options filter files (exclude-newer, no-binary, no-build)" as a setting the tool can't safely edit around.
• Actual: scan exits 0 (redirect_pypi_stale_install / vendor_prebuilt_downloaded only), and the project can no longer be installed.

no-build-package / no-build are fine here: a wheel is allowed, and uv sync --locked passes. A no-binary-package that names a different package is fine too (control).

Matrix (Linux)

Each failing cell reproduced twice, on main 657fce2 and on the v5.0.1 release binary (so it isn't a regression in the 5.0 line). macOS / Windows were not probed: uv's no-binary check is platform-independent.

Suspect code

• Vendored: crates/socket-patch-core/src/vendor/pypi_uv.rs:341 check_target_guards runs refuse_uv_no_sources and refuse_uv_project_shadowing, but nothing for no-binary*.
• Hosted: crates/socket-patch-core/src/patch/redirect/mod.rs:5938-5960 (the same two guards, for project and script).
• The settings readers are already there in crates/socket-patch-core/src/utils/python_script.rs (refuse_uv_no_sources, which reads pyproject / uv.toml / script metadata and *-package lists). A sibling check for no-binary / no-binary-package naming the target, including uv's precedence (uv.toml over [tool.uv]) and the ancestor config lookup, would cover all three lanes.