Summary
The repository documents more than one way to install it, and they do not produce the same environment: following pip install . installs packaging 26.3 from PyPI, while following diffusers/docker/diffusers-onnxruntime-cpu/Dockerfile:29 installs packaging 24.1 from download.pytorch.org/whl/cpu. Nothing in the project indicates that these general-purpose packages should come from the PyTorch index, yet one path silently takes years-old copies from it; users on the two paths run different versions of the same libraries without any visible signal. 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
packaging (transitive):
pip install . (pyproject/requirements only, PyPI) → packaging 26.3 from PyPI
diffusers/docker/diffusers-onnxruntime-cpu/Dockerfile:29 (python3 -m uv pip install --no-cache-dir torch==2.1.2 torchvision==0.16.2 torchaudio==2.1.2 onnxruntime -) → packaging 24.1 from download.pytorch.org/whl/cpu
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 .` (pyproject/requirements only, PyPI)
pip install --dry-run --report a.json "onnxruntime" "torch==2.1.2" "torchaudio==2.1.2" "torchvision==0.16.2"
# -> `packaging 26.3` from PyPI
# B: `diffusers/docker/diffusers-onnxruntime-cpu/Dockerfile:29` (`python3 -m uv pip install --no-cache-dir torch==2.1.2 torchvision==0.16.2 torchaudio==2.1.2 onnxruntime -`)
uv pip compile --emit-index-annotation -o b.txt req.txt --extra-index-url https://download.pytorch.org/whl/cpu # req.txt: "onnxruntime" "torch==2.1.2" "torchaudio==2.1.2" "torchvision==0.16.2"
# -> `packaging 24.1` from download.pytorch.org/whl/cpu
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
packaging: 26.3 (PyPI) vs 24.1 (download.pytorch.org/whl/cpu).
Consequences
- Common packages are pinned to years-old copies from the PyTorch channel under uv (e.g. an outdated CA bundle in
certifi), while pip users get current releases.
- 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
download.pytorch.org hosts old copies of common packages (packaging 24.1 there vs 26.3 on PyPI). uv (first-index) takes the copy from the first index that has the name; pip takes the newest across indexes. Whoever adds the PyTorch channel as an index gets a stale packaging under uv and the current one under pip.
Proposed fix
- Do not let the PyTorch channel serve general-purpose packages: pass it only for the torch packages (
--index-url in a separate step), or in uv mark it explicit = true so packaging always come from PyPI.
- 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
09d9e1941403e7828bf5af7b5ecb286e9fdcb134
- index contents as observed on 2026-09-07; file URLs and sha256 in the table below make the result re-checkable
Selected files
| case |
install path |
package |
version |
index |
file |
sha256 |
| 1 |
pip install . (pyproject/requirements only, PyPI) |
packaging |
26.3 |
PyPI |
packaging-26.3-py3-none-any.whl |
d7193f7c8e4e93f4 |
| 1 |
diffusers/docker/diffusers-onnxruntime-cpu/Dockerfile:29 (python3 -m uv pip install --no-cache-dir torch==2.1.2 torchvision==0.16.2 torchaudio==2.1.2 onnxruntime -) |
packaging |
24.1 |
download.pytorch.org/whl/cpu |
packaging-24.1-py3-none-any.whl |
5b8f2217dbdbd2f7 |
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.
Summary
The repository documents more than one way to install it, and they do not produce the same environment: following
pip install .installspackaging 26.3from PyPI, while followingdiffusers/docker/diffusers-onnxruntime-cpu/Dockerfile:29installspackaging 24.1from download.pytorch.org/whl/cpu. Nothing in the project indicates that these general-purpose packages should come from the PyTorch index, yet one path silently takes years-old copies from it; users on the two paths run different versions of the same libraries without any visible signal. 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
packaging(transitive):pip install .(pyproject/requirements only, PyPI) →packaging 26.3from PyPIdiffusers/docker/diffusers-onnxruntime-cpu/Dockerfile:29(python3 -m uv pip install --no-cache-dir torch==2.1.2 torchvision==0.16.2 torchaudio==2.1.2 onnxruntime -) →packaging 24.1from download.pytorch.org/whl/cpuSteps 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:
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
packaging: 26.3 (PyPI) vs 24.1 (download.pytorch.org/whl/cpu).Consequences
certifi), while pip users get current releases.--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.Root cause
download.pytorch.orghosts old copies of common packages (packaging 24.1 there vs 26.3 on PyPI). uv (first-index) takes the copy from the first index that has the name; pip takes the newest across indexes. Whoever adds the PyTorch channel as an index gets a stalepackagingunder uv and the current one under pip.Proposed fix
--index-urlin a separate step), or in uv mark itexplicit = truesopackagingalways come from PyPI.uv.lock, orpip-compile/pip lockoutput with hashes) and make the README/Dockerfile/CI install from it, so every documented path resolves identical files.Environment
09d9e1941403e7828bf5af7b5ecb286e9fdcb134Selected files
pip install .(pyproject/requirements only, PyPI)packagingd7193f7c8e4e93f4diffusers/docker/diffusers-onnxruntime-cpu/Dockerfile:29(python3 -m uv pip install --no-cache-dir torch==2.1.2 torchvision==0.16.2 torchaudio==2.1.2 onnxruntime -)packaging5b8f2217dbdbd2f7Found 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.