Skip to content

Pin the CI interpreter and its ABI in the update-env step - #632

Open
eriknw wants to merge 2 commits into
mainfrom
ci-pin-python-gil
Open

eriknw wants to merge 2 commits into
mainfrom
ci-pin-python-gil

Conversation

@eriknw

@eriknw eriknw commented Aug 27, 2026

Copy link
Copy Markdown
Member

CI's "Update env" step did not restate python, so conda was free to replace the interpreter setup-miniconda had installed. Three of the last sixteen python 3.14 draws on ubuntu-24.04-arm did exactly that, swapping 3.14.7-*_cp314 for 3.14.7-*_cp314t. Two survived only because they also drew pandas 3.0; the third drew pandas 2.3, whose extension raises a GIL RuntimeWarning on the free-threaded build, and filterwarnings = error turned it into a collection error that took test_formatting.py and test_recorder.py with it. That is the ubuntu-24.04-arm failure on #605.

Re-solving that 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 just not drawn 3.14 with an unlucky pandas yet. linux-64, osx-64 and win-64 pick 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-gil alone constrains only python_abi and leaves its own version open, so python= goes with it.

Checked before pushing:

  • every platform lands on a cp314 build with the pair added
  • no draw becomes unsatisfiable and none 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 the whole pool, and it is a no-op on 3.11/3.12/3.13 today
  • the pypy guard earns its place: pypy python-gil is unsatisfiable, so an unguarded spec would hard-fail a pypy draw if one is added back
  • actionlint and the rest of pre-commit run --all-files pass

Not included: a deliberate 3.14t matrix entry using python-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 for python=3.13 with no ABI spec. It resolves to cp313 today, so nothing is broken, but it is the last conda-solved interpreter in the repo.

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.
@eriknw

eriknw commented Aug 27, 2026

Copy link
Copy Markdown
Member Author

build_and_test (ubuntu-24.04-arm, pytest_normal) is red here for a reason unrelated to this change. That job drew psg=latest, which installed graphblas-10.5.0, and this branch is cut from main, which does not yet carry the 10.5 adaptation:

FAILED graphblas/tests/test_ss_utils.py::test_vector_head[True]     - assert False is True
FAILED graphblas/tests/test_ss_utils.py::test_matrix_head[True]
FAILED graphblas/tests/test_io.py::test_awkward_iso_roundtrip       - assert False
FAILED graphblas/tests/test_formatting.py::test_vector_as_matrix

Those are exactly the four tests #628 fixes: SuiteSparse:GraphBLAS 10.5.0 dropped the post-build iso check, so from_coo with all-equal values no longer comes back iso and the iso arms have to ask for it outright. Any branch off main that draws 10.5 will fail the same four until #628 lands.

The pin itself did what it should on this run: python-3.13.15-hfc9013d_101_cp313 with python_abi-3.13-8_cp313, no ABI swap in the update-env step.

@eriknw

eriknw commented Aug 27, 2026

Copy link
Copy Markdown
Member Author

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 graphblas-10.5.0.

That is not a rare draw. Non-wheel source types install "graphblas>=7.4" unpinned, and conda-forge's latest is now 10.5.0, so most draws land there whatever the psg pool says. Read against main, which this branch is cut from, that means main is currently red on most CI draws, and has been since 10.5.0 reached conda-forge. main has had no push since 2026-08-07, so its own run history does not show it yet.

This PR will stay red until #628 lands. Nothing here changes that, and nothing here causes it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant