Context
The wheel matrix ships GIL builds for CPython 3.11–3.14 across five platforms (manylinux_2_28
x86_64/aarch64 from source, macOS x2, Windows AMD64), with musl canaries on top (#333). Free-threaded
CPython (cp313t / cp314t) is explicitly excluded:
# pyproject.toml [tool.cibuildwheel]
skip = ["*pp*", "*musllinux*", "cp314t-*"]
Status: reactive — blocked on upstream, same model as #335. This issue exists as a tracker so the
free-threaded gap has a number the docs can point at and so the periodic upstream check doesn't get
forgotten.
Related: #332 (from-source Linux stack, shipped), #333 (musl canaries), #334 (win_arm64), #335 (cp315).
Problem / Current Behaviour
Users on a free-threaded interpreter get no wheel: pip falls back to the sdist, which needs a system
GDAL + build chain, and the resulting build still runs with the GIL re-enabled unless every C extension
in the stack declares free-threaded support.
Blockers (all upstream)
- GDAL SWIG bindings — the
osgeo extension modules do not declare Py_mod_gil /
free-threaded readiness; SWIG-generated code needs auditing for GIL-free safety first.
- numpy — free-threaded wheels exist but ABI/behaviour is still stabilising across the versions
pyramids supports.
- Ecosystem — shapely, pyproj, pandas, geopandas (and pyogrio for vector I/O) all need cp31Nt
wheels before pip install pyramids-gis would resolve cleanly on a free-threaded interpreter.
When to act
Revisit at the Python 3.15 cycle (when #335 fires): if GDAL's bindings have declared free-threaded
support and numpy/shapely/pyproj ship cp315t wheels, drop the cp314t-*/cp315t-* skip for a spike
build and run the full test matrix against it (both build models: the from-source Linux stack and the
conda-extract macOS/Windows path).
Affected locations
| File |
Symbol |
Notes |
pyproject.toml |
[tool.cibuildwheel].skip |
remove the cp31Nt-* entry |
.github/workflows/bundle-pypi-wheels.yml |
test-wheels matrix |
add a free-threaded cell |
docs/installation.md / docs/how-to/wheel-build-flow.md |
coverage tables |
flip the row when it ships |
Context
The wheel matrix ships GIL builds for CPython 3.11–3.14 across five platforms (
manylinux_2_28x86_64/aarch64 from source, macOS x2, Windows AMD64), with musl canaries on top (#333). Free-threaded
CPython (
cp313t/cp314t) is explicitly excluded:Status: reactive — blocked on upstream, same model as #335. This issue exists as a tracker so the
free-threaded gap has a number the docs can point at and so the periodic upstream check doesn't get
forgotten.
Related: #332 (from-source Linux stack, shipped), #333 (musl canaries), #334 (win_arm64), #335 (cp315).
Problem / Current Behaviour
Users on a free-threaded interpreter get no wheel: pip falls back to the sdist, which needs a system
GDAL + build chain, and the resulting build still runs with the GIL re-enabled unless every C extension
in the stack declares free-threaded support.
Blockers (all upstream)
osgeoextension modules do not declarePy_mod_gil/free-threaded readiness; SWIG-generated code needs auditing for GIL-free safety first.
pyramids supports.
wheels before
pip install pyramids-giswould resolve cleanly on a free-threaded interpreter.When to act
Revisit at the Python 3.15 cycle (when #335 fires): if GDAL's bindings have declared free-threaded
support and numpy/shapely/pyproj ship cp315t wheels, drop the
cp314t-*/cp315t-*skip for a spikebuild and run the full test matrix against it (both build models: the from-source Linux stack and the
conda-extract macOS/Windows path).
Affected locations
pyproject.toml[tool.cibuildwheel].skipcp31Nt-*entry.github/workflows/bundle-pypi-wheels.ymltest-wheelsmatrixdocs/installation.md/docs/how-to/wheel-build-flow.md