chore(packaging): add Python 3.15 wheels once CPython 3.15 + conda-forge gdal-py3.15 are released

[MAfarrag]

Context

feat/cog (PR #243) ships wheels for Python 3.11, 3.12, 3.13, and 3.14 — the same set the tests.yml
matrix uses. CPython 3.15 is scheduled for release in October 2026; once that ships and conda-forge produces
gdal builds for it (py3.15 selector), pyramids should add it to the matrix.

Status: reactive — fires when CPython 3.15 + conda-forge gdal-py3.15 are both available. No work needed before
then. This issue exists as a tracker so the bump doesn't get forgotten when 3.15 ships.

Related: #331 (master bundling doc), PR #243.

Problem / Current Behaviour

[tool.cibuildwheel].build in pyproject.toml is:

build = ["cp311-*", "cp312-*", "cp313-*", "cp314-*"]

requires-python = ">= 3.11" in [project] has no upper bound, so users on a future Python 3.15 will:

1. pip install pyramids-gis → no wheel matches Python 3.15 ABI → falls back to sdist.
2. sdist build requires GDAL Python bindings to be compilable against the user's Python — needs a system GDAL or a
   working build chain.

The package will still resolve, just less cleanly than the wheel install for users on 3.11-3.14 today.

Affected locations

File	Symbol	Notes
pyproject.toml	[tool.cibuildwheel].build	add "cp315-*"
.github/workflows/build-wheels.yml	test-wheels.strategy.matrix.python-version	add "3.15"
.github/workflows/tests.yml	main-package.matrix.python-version	add "py315" (or "3.15", matching existing rows)
.github/workflows/tests.yml	extras-package.matrix.python-version	same
pyproject.toml	[tool.pixi.environments]	add py315 = ["py315"] + feature env

Steps to Reproduce / Motivation Example

# When Python 3.15 ships (Oct 2026 per PEP schedule):
pyenv install 3.15.0
pyenv local 3.15.0
pip install pyramids-gis
# → falls back to sdist; needs system GDAL.

After this bump:

pip install pyramids-gis
# → resolves cp315-cp315-manylinux_2_39_x86_64.whl directly.

Proposed Solution

Single PR with four small edits:

 # pyproject.toml
-build = ["cp311-*", "cp312-*", "cp313-*", "cp314-*"]
+build = ["cp311-*", "cp312-*", "cp313-*", "cp314-*", "cp315-*"]

 # .github/workflows/build-wheels.yml
 test-wheels:
   strategy:
     matrix:
-      python-version: ["3.11", "3.12", "3.13", "3.14"]
+      python-version: ["3.11", "3.12", "3.13", "3.14", "3.15"]

 # .github/workflows/tests.yml — mirror the matrix bumps

 # pyproject.toml — pixi env for local 3.15 dev
+[tool.pixi.feature.py315.dependencies]
+python = "3.15.*"
+
+[tool.pixi.environments]
+py315 = ["py315"]

Out of Scope

• Removing Python 3.11 support. Decoupled from this bump — 3.11 stays in security-fixes until Oct 2027 per the CPython
  release schedule. When 3.11 hits EOL, that's a separate chore(packaging): drop py311 wheels PR.
• Pre-emptive 3.15 testing via actions/setup-python's pre-release builds. Not worth it — wait for the GA release so
  conda-forge gdal matches.
• Adding free-threaded 3.15t. Currently excluded by [tool.cibuildwheel].skip = ["...", "cp314t-*"]; the same skip
  would extend to cp315t-* until conda-forge ships free-threaded gdal-py3.15t, which is unlikely in the first 3.15
  release cycle.

Effort Estimate

Size: XS
Rationale: ~15 minutes of YAML edits + one CI run to verify the 3.15 wheel builds and tests cleanly.

Definition of Done

• CPython 3.15 released (October 2026 target per PEP).
• pixi search gdal -c conda-forge shows py315 builds available.
• [tool.cibuildwheel].build includes "cp315-*".
• build-wheels.yml and tests.yml matrices include "3.15".
• pyproject.toml has a py315 pixi env.
• pyramids_gis-*-cp315-cp315-*.whl builds and tests pass for all 5 platforms.
• docs/installation.md updated to mention 3.15 support.

[MAfarrag]

Checklist refresh — the pipeline changed since this was written (from-source Linux, win_arm64, one workflow)

The trigger condition is unchanged (reactive: CPython 3.15 GA, ~Oct 2026), but the "affected locations" table
predates the wheel-pipeline rework (#680, #691, #695). Updated map so the bump lands in the right places:

• pyproject.toml [tool.cibuildwheel].build (~L441) — still the single place for the five standard
  platforms: add "cp315-*".
• .github/workflows/bundle-pypi-wheels.yml (replaces the old build-wheels.yml):
  • build-musl-wheels matrix build lists explicit cp311…cp314 musllinux targets — add the cp315 rows
    (canaries).
  • build-winarm64-wheels has its own explicit list (CIBW_BUILD, ~L381: cp312–cp314) and the release
    composition gate asserts pyvers - 1 win_arm64 wheels (~L774). The two carry cross-referencing comments
    and MUST change together. Whether win_arm64 gets cp315 depends on numpy/scipy publishing ARM64 cp315
    wheels; if the five standard platforms gain cp315 but win_arm64 does not, the gate expectation becomes
    pyvers - 2 — either way the gate line is a mandatory touchpoint.
  • test-wheels matrix (~L407) and verify-winarm64 matrix (~L664, if arm gets cp315): add "3.15".
• tests.yml matrix environment: [py311…py314] + a py315 pixi feature/env in pyproject.toml.
• Docs: docs/installation.md supported-versions header and docs/how-to/wheel-build-flow.md wheel counts
  ("23 published wheels", the per-platform table, and the "all platform wheels exist for 3.11–3.14" sentence).

Gating dependency also changed: conda-forge gdal-py3.15 now only matters for the macOS + win_amd64
conda-extract wheels. The Linux wheels build GDAL from source and the win_arm64 wheels build via vcpkg — those
legs instead need CPython 3.15 support in the GDAL SWIG bindings and cp315 wheels for the binary dep closure
(numpy/scipy/pandas/pyproj/cftime).