Stray torchvision==0.27.1+df56172 (win_arm64-only) wheel on the stable /whl/cpu index breaks resolvers

[tmokmss]

🐛 Describe the bug

A stray, mis-published wheel is present on the stable CPU wheel index:

https://download.pytorch.org/whl/cpu/torchvision/
  -> torchvision-0.27.1+df56172-cp311-cp311-win_arm64.whl

What looks wrong about it:

• The local-version label +df56172 looks like a leaked build/commit hash. The proper CPU build for this release is 0.27.1+cpu.
• It ships only a single win_arm64 wheel, yet it is published under /whl/cpu.
• It exists only on /whl/cpu. It is absent from /whl/cu126, /whl/cu128, and /whl/nightly/cpu.

Because +df56172 sorts higher than +cpu as a PEP 440 local version, resolvers that use a "best match across indexes" strategy pick 0.27.1+df56172 and then fail on Linux x86_64, where it has no compatible wheel. We hit this in CI with uv sync pointed at the CPU index (--index ...=https://download.pytorch.org/whl/cpu --index-strategy unsafe-best-match):

error: Distribution `torchvision==0.27.1+df56172 @ registry+https://download.pytorch.org/whl/cpu` can't be installed because it doesn't have a source distribution or wheel for the current platform
hint: You're on Linux (`manylinux_2_39_x86_64`), but `torchvision` (v0.27.1+df56172) only has wheels for the following platform: `win_arm64`; consider adding "sys_platform == 'linux' and platform_machine == 'x86_64'" to `tool.uv.required-environments` to ensure uv resolves to a version with compatible wheels

Minimal demonstration that the artifact is non-installable on the CPU index's primary platform (Linux x86_64 / CPython 3.11):

uv pip install --dry-run --no-deps \
  --python-platform x86_64-manylinux_2_28 --python-version 3.11 \
  --index-url https://download.pytorch.org/whl/cpu \
  "torchvision==0.27.1+df56172"

  x No solution found when resolving dependencies:
  `-> Because torchvision==0.27.1+df56172 has no wheels with a matching
      platform tag (e.g., `manylinux_2_28_x86_64`) and you require
      torchvision==0.27.1+df56172, we can conclude that your requirements
      are unsatisfiable.

For comparison, requesting torchvision==0.27.1 (without the local label) resolves cleanly to 0.27.1+cpu — so the only problem is the stray +df56172 artifact polluting the index.

Context: why unsafe-best-match is involved

For completeness, here is why our resolver hits this. We use the common uv pattern for installing CPU-only torch/torchvision in CI while keeping a single CUDA-pinned lockfile. torch/torchvision are pinned to a pytorch-cu126 index via [tool.uv.sources] (so the committed uv.lock holds +cu126 entries), and CI installs the CPU build by overriding that index at sync time:

uv sync --index pytorch-cu126=https://download.pytorch.org/whl/cpu --index-strategy unsafe-best-match

--index-strategy unsafe-best-match is required here so uv can reconcile the locked +cu126 entries against the CPU index. On a clean index this correctly resolves torchvision to 0.27.1+cpu; the failure only appears because 0.27.1+df56172 sorts higher than 0.27.1+cpu as a PEP 440 local version, so best-match picks the stray win_arm64-only artifact. In other words, the resolver configuration is behaving as designed — the stray wheel is the sole cause.

Expected behavior

torchvision-0.27.1+df56172-cp311-cp311-win_arm64.whl should not be present on the stable /whl/cpu index. Please yank/remove it, and check how a +df56172-tagged, win_arm64-only wheel leaked into the CPU index (publishing pipeline).

Versions

This is a packaging/index issue rather than a runtime bug, so collect_env.py is not applicable (the offending artifact cannot be installed). Relevant details:

• Intended package: torchvision 0.27.1, CPU build (+cpu)
• Offending artifact: torchvision-0.27.1+df56172-cp311-cp311-win_arm64.whl on https://download.pytorch.org/whl/cpu
• Platform where it breaks: Linux x86_64 (manylinux_2_28 / manylinux_2_39), CPython 3.11
• Resolver: uv 0.11.0 with --index-strategy unsafe-best-match (any "best-match-across-indexes" resolver is affected)
• Index presence: present on /whl/cpu; absent on /whl/cu126, /whl/cu128, /whl/nightly/cpu

---

Related: #9470 (a similar index/wheel inconsistency on download.pytorch.org)

[NicolasHug]

CC @atalman any clue why there are wheels with commit tags on S3? It's not just 0.27.1, I also see e.g. torchvision-0.24.1+d801a34-cp311-cp311-win_arm64.whl

[hsanzg]

This broke our CI on Friday, so we had to pin our torchvision version to 0.27.0+cpu. Unfortunately that also broke today:

Downloading torchvision (1.7MiB)
  × Failed to download `torchvision==0.27.0+cpu`
  ├─▶ Failed to extract archive:
  │   torchvision-0.27.0+cpu-cp313-cp313-manylinux_2_28_x86_64.whl
  ├─▶ I/O operation failed during extraction
  ╰─▶ Failed to download distribution due to network timeout. Try increasing
      UV_HTTP_TIMEOUT (current value: 30s).
hint: `torchvision` (v0.27.0+cpu) was included because `home:cpu` depends on `torchvision`

Any ideas on how to fix this temporarily with uv?

False alarm, resolution of 0.27.0 seems to be working now.