You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TST: devdeps on weekly cron not installing numpy-dev #20196
On the weekly cron job, devdeps with and without scipy installs numpy 2.4.6 . I expected it to be consistent with devdeps on regular CI and should have installed numpy 2.6.0.dev (at the time of writing).
Ah, I think I understand the issue; This job is still on Python 3.11, but numpy stopped shipping wheels for it in 2.5.0. The installer (uv) doesn't even attempt to build 2.6.0dev0 from source because we explicitly forbid source installs for numpy (very much intentional).
It should be sufficient to upgrade Python itself on these jobs, though this leaves me with a question: why are we testing the combination of an "old" Python with numpy's dev version ? If this is the intention behind this job, this silent failure mode will happen again every time numpy devs decide to drop a Python version. It might be that it's acceptable, but we really ought to better document it so we don't have to re-discover the explanation every year.
Depending on the reply, we could upgrade the interpreter to either 3.12 (oldest version still supported upstream) or 3.14 (newest stable version with wheels available for all packages required), or even 3.15 (pre-releases), which in my opinion is more in line with what we should be testing. I'll open a PR with 3.15 to see wether there are any blockers there.
Activity
neutrinoceros commentedon Aug 4, 2026
Relevant excerpt, confirming that pre-releases are correctly allowed in resolution
neutrinoceros commentedon Aug 4, 2026
Ah, I think I understand the issue; This job is still on Python 3.11, but numpy stopped shipping wheels for it in 2.5.0. The installer (uv) doesn't even attempt to build 2.6.0dev0 from source because we explicitly forbid source installs for numpy (very much intentional).
It should be sufficient to upgrade Python itself on these jobs, though this leaves me with a question: why are we testing the combination of an "old" Python with numpy's dev version ? If this is the intention behind this job, this silent failure mode will happen again every time numpy devs decide to drop a Python version. It might be that it's acceptable, but we really ought to better document it so we don't have to re-discover the explanation every year.
neutrinoceros commentedon Aug 4, 2026
Depending on the reply, we could upgrade the interpreter to either 3.12 (oldest version still supported upstream) or 3.14 (newest stable version with wheels available for all packages required), or even 3.15 (pre-releases), which in my opinion is more in line with what we should be testing. I'll open a PR with 3.15 to see wether there are any blockers there.