Intermittent CI failures related to unpacking packages

[srittau]

We get intermittent failures in CI during the "pyright: Run test cases" step. The failure is always consistent between all three platform this test runs on, and also look consistent within a PR, but the packages it affects are different between PRs. The affected packages have no new releases.

Example from https://github.com/python/typeshed/actions/runs/15062531917/job/42340224286?pr=14078

Run DEPENDENCIES=$( python tests/get_external_stub_requirements.py )
  DEPENDENCIES=$( python tests/get_external_stub_requirements.py )
  if [ -n "$DEPENDENCIES" ]; then
      printf "Installing packages:\n  $(echo $DEPENDENCIES | sed 's/ /\n  /g')\n"
      uv pip install --python-version 3.14 $DEPENDENCIES
  fi
  shell: /usr/bin/bash -e {0}
  env:
    PIP_DISABLE_PIP_VERSION_CHECK: 1
    FORCE_COLOR: 1
    pythonLocation: /opt/hostedtoolcache/Python/3.13.3/x64
    PKG_CONFIG_PATH: /opt/hostedtoolcache/Python/3.13.3/x64/lib/pkgconfig
    Python_ROOT_DIR: /opt/hostedtoolcache/Python/3.13.3/x64
    Python[2](https://github.com/python/typeshed/actions/runs/15062531917/job/42340224286?pr=14078#step:8:2)_ROOT_DIR: /opt/hostedtoolcache/Python/3.13.3/x64
    Python3_ROOT_DIR: /opt/hostedtoolcache/Python/[3](https://github.com/python/typeshed/actions/runs/15062531917/job/42340224286?pr=14078#step:8:3).13.3/x64
    LD_LIBRARY_PATH: /opt/hostedtoolcache/Python/3.13.3/x6[4](https://github.com/python/typeshed/actions/runs/15062531917/job/42340224286?pr=14078#step:8:4)/lib
    UV_CACHE_DIR: /home/runner/work/_temp/setup-uv-cache
Installing packages:
  Flask-SQLAlchemy>=3.0.1
  Flask>=0.9
  Flask>=2.0.0
  Flask>=2.3.2
  MarkupSafe
  Pillow>=10.3.0
  arrow>=1.0.1
  click>=8.0.0
  cryptography
  cryptography>=3[7](https://github.com/python/typeshed/actions/runs/15062531917/job/42340224286?pr=14078#step:8:7).0.0
  django-stubs
  matplotlib>=3.[8](https://github.com/python/typeshed/actions/runs/15062531917/job/42340224286?pr=14078#step:8:8)
  numpy>=1.20
  numpy>=1.21
  numpy>=2.0.0rc1
  pandas-stubs
  pyproj
  referencing
  tree-sitter>=0.20.3
  urllib3>=2
Resolved 41 packages in 282ms
Downloading cryptography (4.0MiB)
Downloading sqlalchemy (1.8MiB)
Downloading fonttools (1.1MiB)
Downloading django (7.[9](https://github.com/python/typeshed/actions/runs/15062531917/job/42340224286?pr=14078#step:8:9)MiB)
  × Failed to download and build `matplotlib==3.[10](https://github.com/python/typeshed/actions/runs/15062531917/job/42340224286?pr=14078#step:8:10).3`
  ├─▶ Failed to extract archive: matplotlib==3.10.3
  ╰─▶ bzip2: bz2 header missing
Error: Process completed with exit code 1.

The errors started yesterday and yesterday a new uv version was released, but we pinned uv to an old version, which also gets installed.

[srittau]

I think the problem is that "pyright: Run test cases" uses astral-sh/setup-uv@v5, but then follows it with uv pip install -r requirements-tests.txt --system. #14081 indicates that the uv version installed by astral-sh/setup-uv@v5 is used, which might somehow still conflict with the uv version explicitly installed from the requirements. After updating the requirements to the same version the actions is installed, the problem went away.

[AlexWaygood]

Maybe we should be pinning the uv version we install in the setup-uv action to the same version we have in requirements-tests.txt

[srittau]

That's what I was thinking, although ideally we'd automate that or teach renovate to sync it.

[Avasam]

There's some mentions of bzip2 support in the last two versions of uv. Which is what the CI fails on. Likely related.

In any case I agree we should use a consistent version from our pinned dependencies.

I wonder if setup-uv can/could automatically pickup the version from dependency groups like the ruff action can.

[srittau]

For as long as we're using a requirements file, I've opened astral-sh/setup-uv#411.

[srittau]

(And of course #14082 is a workaround for now.)