`torch` resolves to 2.14.0+xpu (download.pytorch.org/whl/xpu) or 2.9.1+cu128 (download.pytorch.org/whl/cu128) depending on install path (pip install .` with the index configuration committed in the repo)

Summary

The repository documents more than one way to install it, and they do not produce the same environment: following pip install . with the index configuration committed in the repo installs torch 2.14.0+xpu from download.pytorch.org/whl/xpu, while following uv sync / uv pip install . installs torch 2.9.1+cu128 from download.pytorch.org/whl/cu128. A user who reads the README/Dockerfile expects the CUDA/ROCm build named there, but depending on the installer and index order gets a different variant or major version, which is confusing to debug (GPU silently unused, mismatched CUDA libraries) and means the two paths are not tested against the same dependencies. Because the selection is decided by index visibility and installer semantics rather than by the project, it is also an exposure: whichever index publishes a higher version of these names decides what gets installed.

Description

torch:

• pip install . with the index configuration committed in the repo → torch 2.14.0+xpu from download.pytorch.org/whl/xpu
• uv sync / uv pip install . (pyproject with [tool.uv.sources]) → torch 2.9.1+cu128 from download.pytorch.org/whl/cu128

Steps to reproduce

Dry-run resolutions (nothing is installed), Python 3.11, Linux x86_64, pip 26.2.1 / uv 0.12.10, index state of 2026-09-07:

# A: `pip install .` with the index configuration committed in the repo
pip install --dry-run --report a.json "torch" --extra-index-url https://download.pytorch.org/whl/xpu --extra-index-url https://download.pytorch.org/whl/cu128 --extra-index-url https://download.pytorch.org/whl/rocm6.3 --extra-index-url https://download.pytorch.org/whl/nightly/cpu --extra-index-url https://download.pytorch.org/whl/cu124
#   -> `torch 2.14.0+xpu` from download.pytorch.org/whl/xpu

# B: `uv sync` / `uv pip install .` (pyproject with `[tool.uv.sources]`)
uv lock   # in the repo checkout (honours [tool.uv.sources]); or: uv pip compile --emit-index-annotation -o b.txt req.txt --extra-index-url https://download.pytorch.org/whl/xpu --extra-index-url https://download.pytorch.org/whl/cu128 --extra-index-url https://download.pytorch.org/whl/rocm6.3 --extra-index-url https://download.pytorch.org/whl/nightly/cpu --extra-index-url https://download.pytorch.org/whl/cu124   # req.txt: "torch"
#   -> `torch 2.9.1+cu128` from download.pytorch.org/whl/cu128

Expected behavior

Every documented install path selects the same file for the package(s) above (same version, same index, same hash), or the documentation states which build is intended.

Actual behavior

• torch: 2.14.0+xpu (download.pytorch.org/whl/xpu) vs 2.9.1+cu128 (download.pytorch.org/whl/cu128).

Consequences

• Users following one path get a different PyTorch build (CUDA/ROCm/CPU variant or major version) than users following the other; GPU code may run on CPU or fail to load CUDA libraries.
• The environment produced by one path is not the one exercised in CI, so bug reports are hard to reproduce.
• With --extra-index-url, pip installs whichever index publishes the highest version of a name. For unpinned names this means any index in the set (or anyone able to publish to it) can decide which artifact is installed; this is the pre-condition of dependency-confusion attacks.
• The two paths install files with different hashes from different indexes; which build (and whose build) ends up in the environment is decided by index order and installer behaviour rather than by the project's declaration, and the two files were not verified against each other here.

Root cause

The two paths expose different index sets; each resolver picks the highest version among the indexes it sees, so the selected release depends on the path. [tool.uv.sources] is honoured only by uv; every pip install command in the docs/Dockerfile ignores it and resolves from the indexes on its own command line.

Where the repo binds these packages to an index

• pyproject.toml:60 — torch → https://download.pytorch.org/whl/cu128
• uv.lock — torch → https://download.pytorch.org/whl/cu128 (uv.lock: torch==2.7.0+cu128 from pytorch:cu128)
• requirements_ipex_xpu.txt:4 — torch → https://download.pytorch.org/whl/xpu (torch==2.7.1+xpu)
• requirements_linux.txt:4 — torch → https://download.pytorch.org/whl/cu128 (torch==2.7.0+cu128)
• requirements_linux_rocm.txt:5 — torch → https://download.pytorch.org/whl/rocm6.3 (torch==2.7.1+rocm6.3)
• requirements_pytorch_windows.txt:4 — torch → https://download.pytorch.org/whl/cu128 (torch==2.7.0+cu128)
• requirements_runpod.txt:2 — torch → https://download.pytorch.org/whl/cu124 (torch==2.5.0+cu124)

Proposed fix

1. Pin the channel build explicitly in the install command(s) (README/Dockerfile/CI): e.g. torch==<ver>+xpu --index-url https://download.pytorch.org/whl/xpu instead of unpinned names.
2. Install the PyTorch packages in a dedicated step with --index-url <channel> (single index), then install the remaining requirements from PyPI. Avoid --extra-index-url for the channel: with pip it makes PyPI's newer release win.
3. For uv, declare the channel explicit = true and bind the packages to it so uv never takes them from PyPI:

[[tool.uv.index]]
name = "pytorch"
url = "https://download.pytorch.org/whl/xpu"
explicit = true

[tool.uv.sources]
torch = { index = "pytorch" }

1. Commit a lock (uv.lock, or pip-compile/pip lock output with hashes) and make the README/Dockerfile/CI install from it, so every documented path resolves identical files.

Environment

• pip 26.2.1, uv 0.12.10, CPython 3.11, Linux x86_64 (Ubuntu 24.04 on WSL2)
• repository at commit 45088f04af78e11cec5407ff4652ea3ed2c14422
• index contents as observed on 2026-09-07; file URLs and sha256 in the table below make the result re-checkable

Selected files

Found by an automated check that resolves the declared dependencies under each documented install path and diffs the selected files. File URLs and sha256 hashes are listed above so the result can be re-checked independently.