GeezerVison

What is broken

make lock-python-dependencies-all cannot complete on master. It aborts after compiling the first file:

ValueError: Missing CPU hashes for torch==2.14.1+cpu
make: *** [lock-python-dependencies-all] Error 1

Because the target begins with rm -rf sdk/python/requirements/*, a run leaves the tree with 14 of the 15 requirements files deleted and nothing regenerated.

Why

uv pip compile --universal --torch-backend cpu splits torch by marker, so the lock holds two pins per package. This is the shape in all three committed py3.*-ci-requirements.txt today:

torch==2.14.0 ; sys_platform == 'darwin'
torch==2.14.0+cpu ; sys_platform != 'darwin'
torchvision==0.29.0 ; sys_platform == 'darwin'
torchvision==0.29.0+cpu ; sys_platform != 'darwin'

add_hashes looked every entry up by appending +cpu to its version:

hashes = cpu_hashes.get((name, f"{version}+cpu"))

For the second pin of each pair that asks for 2.14.0+cpu+cpu, which no resolve can produce, so the lookup missed and the script raised.

Why the tests did not catch it

test_cpu_hashes_preserve_pypi_hashes_and_pins feeds in a bare torch==2.13.0 and nothing else, so the +cpu pin that a real --universal resolve emits is never exercised. The script and its tests landed together in #6188, and the requirements files were last regenerated before that, so the target appears not to have been run since.

The change

The +cpu pin is already the CPU wheel, so it needs no hashes added and is now returned untouched.

Returning it, rather than normalising the lookup key to version.removesuffix("+cpu") + "+cpu", is deliberate: both stop the crash, but normalising would union the CPU resolve's hashes into that entry and could widen the set of artifacts the pin accepts. Returning it leaves the hash set exactly as the resolver wrote it, so no lock can start accepting an artifact it did not accept before.

A genuine version mismatch still raises, which the existing third test covers unchanged.

Verification

Two tests added, for a single marker split and for the torch + torchvision pair the lock actually contains, both asserting idempotency. sdk/python/tests/unit/infra/scripts/test_cpu_torch_hashes.py: 4 passed.

Checked against real data — add_cpu_hashes run over each committed file with the CPU pins a --torch-backend cpu --no-deps resolve would return:

ruff check and ruff format --check clean.

I found this trying to satisfy a review on #6958, which asks for regenerated locks and cannot be done until this is fixed.