Review: numba PR #10809 — CI: use --pre for llvmlite installs on wheel builder workflows

• Reviewer: Kilo (Anthropic/claude-sonnet-5)
• URL: #10809
• Author: swap357
• Branch: swap357/numba:gha/llvmlite_pip_install_pre -> main
• Base: main @ 3598bdd
• Head: 5bc95a26
• State at review time: open, mergeable, all 111 CI checks green

Verified against real CI logs, not just check-run conclusions ✅

Checked out this PR and, in addition to the check-run conclusions, pulled the actual GitHub Actions job logs to confirm the fix behaves as intended (not just "CI is green").

Fix is correctly scoped and exhaustive

• Confirmed on main (pre-PR): exactly 4 build-time pip install ... llvmlite sites were missing --pre:

  • buildscripts/github/build_wheel_linux.sh (shared by both linux-64 and linux-aarch64 — one script fix covers both platforms)
  • one each in numba_osx-arm64_wheel_builder.yml, numba_win-64_wheel_builder.yml, numba_win-arm64_wheel_builder.yml

  Test-time installs in all 5 platforms already had --pre prior to this PR — matches the description exactly.

• Post-PR: no build-time install from WHEELS_INDEX_URL is missing --pre anywhere in the repo.

• --pre is applied to a dedicated pip install call that installs only llvmlite, against a project-scoped index (pypi.anaconda.org/numba/label/dev/simple, not public PyPI) — no risk of it affecting resolution of numpy/setuptools/wheel/tbb or pulling in pre-releases of unrelated packages.

• All 111 CI checks pass (note: total_count is 111 > the 100-per-page API default, so a second page is needed to see the full set — e.g. win-arm64-build-wheel only shows up on page 2).

Log-verified: the fix resolves the correct version, everywhere

Pulled the real build-wheel job log for one job per platform and checked exactly what pip install --pre ... llvmlite resolved to:

For comparison, I also checked a build job for #10804 (which doesn't have this fix): the same build step there resolves llvmlite==0.49.0, stable, manylinux2014-tagged — i.e. exactly the bug this PR describes, reproduced live in CI, not just theoretical.

One thing to flag: linux-64 needs #10804 too, to get the full benefit

linux-64 resolved dev1 (still manylinux2014-tagged) rather than the newer dev2, which is published on the dev index with a manylinux_2_28_x86_64 tag. This is not a bug in this PR — the linux-64 build container on this branch is still quay.io/pypa/manylinux2014_x86_64 (glibc 2.17), so pip correctly refuses the manylinux_2_28 wheel (glibc 2.28 floor) as tag-incompatible with the running container, and falls back to the newest compatible pre-release instead. linux-aarch64 doesn't hit this because that container was already manylinux_2_28_aarch64 before either PR.

Confirmed this end-to-end via the resulting numba wheel tags too:

• linux-64 output: numba-...-manylinux2014_x86_64.manylinux_2_17_x86_64.whl
• linux-aarch64 output: numba-...-manylinux_2_27_aarch64.manylinux_2_28_aarch64.whl

— exactly matching each container's glibc floor.

Practical implication: --pre (this PR) is necessary but, for linux-64 specifically, not sufficient on its own — it needs #10804 (which switches linux-64's container to manylinux_2_28_x86_64) to land as well before linux-64 builds actually consume a manylinux_2_28-tagged llvmlite. It's already fully sufficient today for linux-aarch64/osx-arm64/win-64/win-arm64.

Recommendation

Approve. The fix is minimal, precisely targets the described bug, and is verified working end-to-end in real CI logs across all 5 platforms. Suggest landing this together with (or immediately before) #10804 so linux-64 gets the intended manylinux_2_28 llvmlite at build time from day one, rather than silently continuing on manylinux2014 for one more cycle.