`packaging` resolves to 26.3 (PyPI) or 24.1 (download.pytorch.org/whl/cpu) depending on install path (diffusers/docker/diffusers-onnxruntime-cpu/Dockerfile:29)

Start with diffusers/docker/diffusers-onnxruntime-cpu/Dockerfile:29 and compare it with the documented pip install path in the project configuration and README. Re-run the provided pip and uv dry-run commands to confirm how packaging is selected from each index. Done means the documented paths resolve the same intended files, or clearly document the intended differing builds, with the Dockerfile, lock data, and CI aligned.

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

1. 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.
2. 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.