Conversation
conda-forge ships two ABIs for CPython 3.13+, and the "Update env" step did not restate ``python``, so the solver was free to replace the interpreter setup-miniconda installed. Three of the last sixteen python 3.14 draws on ubuntu-24.04-arm did exactly that: the log reads ``python 3.14.7-h6bfacdd_100_cp314 --> 3.14.7-hefd156b_0_cp314t`` and pytest then reports "Python: 3.14.7 free-threading build". Two of the three passed only because they also drew pandas 3.0. The third drew pandas 2.3, whose extension raises "The global interpreter lock (GIL) has been enabled to load module 'pandas._libs.pandas_parser'", and ``filterwarnings = error`` turns that into a collection error. It took test_formatting.py and test_recorder.py down with it, the second only because the first had left pandas half-imported. The window opened on 2026-08-19, when conda-forge uploaded python 3.14.7 for linux-aarch64 in both ABIs. Re-solving the failing job's own spec set per platform: linux-aarch64 and osx-arm64 both pick ``cp314t`` today, so macos-latest is on the same fuse and has simply not drawn 3.14 with an unlucky pandas yet. linux-64, osx-64 and win-64 pick the GIL build either way, which is why this has been an arm-only symptom. ``python-gil`` pins ``python_abi``; restating ``python=`` pins the version, since ``python-gil`` alone constrains only the ABI and its own version is left open. setup-miniconda's ``python-version`` is equally ABI-free, so this step is where both get settled. Re-solved with the pair added: every platform lands on a ``cp314`` build, and no draw becomes unsatisfiable or downgrades numpy, numba, pandas or psg, including python 3.11 with numpy 1.24 and scipy 1.9. python-gil has builds for 3.9 through 3.14, so one spec covers every version in the pool. The pypy guard matches the neighbouring lines: ``pypy python-gil`` is unsatisfiable, so an unguarded spec would hard-fail a pypy draw if one is ever added back. python-suitesparse-graphblas pins the same pair in ``.github/workflows/test.yml``, and asks for ``python-freethreading`` on the matrix entries that want the other ABI. An entry like that would be worth having here too, but it is a coverage decision rather than a fix, so it is not in this commit.
|
Those are exactly the four tests #628 fixes: SuiteSparse:GraphBLAS 10.5.0 dropped the post-build iso check, so The pin itself did what it should on this run: |
|
Follow-up on the red jobs, because the scale changed the picture: eight of eight failing jobs on the latest run are the same four tests, and every one of them installed That is not a rare draw. Non- This PR will stay red until #628 lands. Nothing here changes that, and nothing here causes it. |
CI's "Update env" step did not restate
python, so conda was free to replace the interpretersetup-minicondahad installed. Three of the last sixteen python 3.14 draws onubuntu-24.04-armdid exactly that, swapping3.14.7-*_cp314for3.14.7-*_cp314t. Two survived only because they also drew pandas 3.0; the third drew pandas 2.3, whose extension raises a GILRuntimeWarningon the free-threaded build, andfilterwarnings = errorturned it into a collection error that tooktest_formatting.pyandtest_recorder.pywith it. That is theubuntu-24.04-armfailure on #605.Re-solving that job's own spec set per platform:
linux-aarch64andosx-arm64both pickcp314ttoday, somacos-latestis on the same fuse and has just not drawn 3.14 with an unlucky pandas yet.linux-64,osx-64andwin-64pick the GIL build either way.The fix follows the precedent already in
python-suitesparse-graphblas(.github/workflows/test.yml): pin the version and the ABI together.python-gilalone constrains onlypython_abiand leaves its own version open, sopython=goes with it.Checked before pushing:
cp314build with the pair addedpython-gilhas builds for 3.9 through 3.14, so one spec covers the whole pool, and it is a no-op on 3.11/3.12/3.13 todaypypy python-gilis unsatisfiable, so an unguarded spec would hard-fail a pypy draw if one is added backactionlintand the rest ofpre-commit run --all-filespassNot included: a deliberate
3.14tmatrix entry usingpython-freethreading, the way psg does it. That is worth having, but it is a coverage decision rather than a fix, and the pandas GIL warning would need handling on that entry.One place left unpinned:
docs/env.yml(used by readthedocs) asks forpython=3.13with no ABI spec. It resolves tocp313today, so nothing is broken, but it is the last conda-solved interpreter in the repo.