GeezerVison

#6906 taught add_cpu_hashes to leave an existing +cpu pin alone, which is what make lock-python-dependencies-all needed to get past:

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

That behaviour is still untested, and the gap is the reason the target could ship unable to run at all.

Both existing tests pass a bare torch==2.13.0 as the requirements being patched, and put +cpu only in cpu_requirements — the lookup table. So neither exercises a +cpu entry on the side that gets rewritten, which is exactly the input a real resolve produces:

torch==2.13.0 ; sys_platform == 'darwin'
torch==2.13.0+cpu ; sys_platform != 'darwin'

What is added

Two tests, no production code:

• one for a single marker split
• one for the torch + torchvision pair the committed py3.*-ci-requirements.txt actually contain

Both assert idempotency. The second also asserts the +cpu line is left exactly as the resolver wrote it rather than merged into, so a later change cannot widen the set of artifacts that pin accepts without failing here — that property is the reason skipping is preferable to normalising the lookup key, and nothing currently holds it in place.

Verification

sdk/python/tests/unit/infra/scripts/test_cpu_torch_hashes.py: 4 passed. They pass against #6906's fix as merged, with the script untouched — so they describe the behaviour rather than one implementation of it.

ruff check and ruff format --check clean.

I had opened #6959 proposing the same fix before #6906 merged; the approach there was identical (return match[0] for a +cpu pin), and #6906 additionally normalises pins in main(), which mine did not. I have closed #6959 in favour of this, which keeps only the part that is still missing.