What this PR does / why we need it:

Every CI job currently fails in the install step:

× Failed to download `torchvision==0.28.0+cpu`
╰─▶ Hash mismatch for `torchvision==0.28.0+cpu`

The CI requirement files are compiled without a torch backend, so their hashes describe PyPI wheels, but install-python-dependencies-ci synced them on Linux with --torch-backend cpu, which serves the +cpu builds from download.pytorch.org. Those are different artifacts with different hashes.

The divergence has existed since #6588 added the flag to sync only; what changed is verification. uv 0.12.11 began applying hashes from public-version pins to matching local versions when no exact local-version hash is provided, so the PyPI hashes recorded for torchvision==0.28.0 are now checked against the +cpu wheel. Earlier releases found no hash for the local version and skipped the check. uv is unpinned in the workflows, so CI moved from 0.12.7 to 0.12.11 and every job began failing.

Approach

Compile and sync now both pass --torch-backend cpu, so they can no longer disagree about where torch comes from.

The CI locks are compiled --universal so one file serves both the Linux and macOS runners, pinning each variant with its own hashes:

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

Without --universal the lock pins an unmarked torch==2.13.0 carrying PyPI hashes. Linux still resolves that to 2.13.0+cpu, because ==2.13.0 matches the local version under PEP 440, and the download then fails verification — the original breakage in a different guise.

An explicit index with [tool.uv.sources] does not serve here. The pip interface applies sources only at compile time; uv pip sync ignores them, so the +cpu builds would not be found at all.

No nvidia-* package remains in any CI requirements file, which is what #6588 set out to achieve.

pixi raises its uv floor to 0.6.9, the first release with --torch-backend. The uv already locked in infra/scripts/pixi/pixi.lock satisfies it, so that lock is untouched.

Dependency bounds

Recompiling exposed five dependencies with no upper bound, which float into regressions on every recompile. Two of them are already breaking jobs on this PR's own CI:

• mcp — 1.30 stops returning the mcp-session-id response header, so the handshake in mcp-feature-server-runtime fails (the server itself starts fine). 98e5bca already pinned 1.29.0 in the lock files; the bound makes that durable instead of resettable on the next recompile.
• ray — 2.56+ returns its own extension dtypes from ray.data, failing 17 assertions in test_universal_types.py (is_object_dtype(TensorDtype(...)) → False). feast declares ray directly only on 3.10, so the bound is repeated for 3.11+ where ray arrives transitively through codeflare-sdk.
• pyarrow, mlflow — capped at the versions 3.10 and 3.11 already lock to, so all three interpreters agree.

Every cap holds a package at a version already present on master. The bounds also bring two interpreters back in line with the others: py3.10 was at ray==2.56.1, and py3.12 at pyarrow==24.0.0 / mlflow==3.14.0, where 3.10 and 3.11 sat at 21.0.0 / 3.2.0.

pixi.lock moves pyarrow 24.0.0 → 21.0.0 in all four environments and nothing else — pyproject.toml is the root pixi manifest, so the bound invalidates the lock and setup-pixi checks it.

The locks were recompiled in place over the existing files, which uv uses as preference anchors; that is what keeps the diff at ~1,200 lines rather than tens of thousands.

Which issue(s) this PR fixes:

None filed; this repairs CI on master.

Checks

• I've made sure the tests are passing.
• My commits are signed off (git commit -s)
• My PR title follows conventional commits format

Testing Strategy

• Unit tests
• Integration tests

Verified locally on a macOS host, under uv 0.12.13 — the release line whose stricter hash checking broke CI — so the full Linux install was not exercised end to end:

• uv pip sync --dry-run --python-platform x86_64-unknown-linux-gnu --torch-backend cpu against py3.11-ci-requirements.txt resolves all 445 packages and selects torch==2.13.0+cpu and torchvision==0.28.0+cpu.
• A real hash-checked install of the CPU torchvision wheel for the Linux platform downloads from download.pytorch.org and verifies clean — the specific artifact that was failing.
• The same install against master's lock entry reproduces the failure, confirming --universal is load-bearing rather than cosmetic.
• pixi lock --check (pixi 0.75.0, the version CI pins) is clean on master and reports pyarrow as the only movement under the new bounds.

CI on this PR is the actual proof.

🤖 Generated with Claude Code