ci: pin the build toolchain (cibuildwheel, build, scikit-build-core)

.github/workflows/wheels.yml

@@ -87,7 +87,13 @@ jobs:
           python-version: "3.12"
 
       - name: Install cibuildwheel
-        run: pip install cibuildwheel
+        # Pinned. cibuildwheel builds, repairs and TESTS every wheel published
+        # from this workflow, so an unpinned release retroactively changes what
+        # ships -- the same failure mode that took ruff, nanobind and GitPython
+        # out. It had already happened here quietly: the 3.x -> 4.x major landed
+        # unnoticed, and the wheels for 5.10.2 were built by a version nobody
+        # chose. Bump deliberately, and re-read the arch note below when you do.
+        run: pip install cibuildwheel==4.2.0
 
       - name: Build and test a repaired wheel (discarded)
         # Relative path, matching build-wheels below: an absolute /tmp is not a
@@ -228,7 +234,13 @@ jobs:
           python-version: "3.12"
 
       - name: Install cibuildwheel
-        run: pip install cibuildwheel
+        # Pinned. cibuildwheel builds, repairs and TESTS every wheel published
+        # from this workflow, so an unpinned release retroactively changes what
+        # ships -- the same failure mode that took ruff, nanobind and GitPython
+        # out. It had already happened here quietly: the 3.x -> 4.x major landed
+        # unnoticed, and the wheels for 5.10.2 were built by a version nobody
+        # chose. Bump deliberately, and re-read the arch note below when you do.
+        run: pip install cibuildwheel==4.2.0
 
       - name: Build wheels
         run: cibuildwheel --output-dir wheelhouse
@@ -241,8 +253,8 @@ jobs:
           # and on Linux whatever the runner itself is -- x86_64 on ubuntu-22.04,
           # aarch64 on ubuntu-22.04-arm. That is why the arm64 wheel needs no
           # CIBW_ARCHS_LINUX override: the runner, not the arch list, selects it.
-          # (Linux i686 was already dropped from "auto" in cibuildwheel 3.0, so
-          # it is not a factor here.)
+          # (Linux i686 was dropped from "auto" in cibuildwheel 3.0, so it is not
+          # a factor at the pinned 4.2.0 either.)
           CIBW_ARCHS: "auto64"
           CIBW_BUILD: "cp310-* cp311-* cp312-*"
           CIBW_SKIP: "*-musllinux*"
@@ -269,7 +281,9 @@ jobs:
       - uses: actions/setup-python@v7
         with:
           python-version: "3.12"
-      - run: pip install build
+      # Pinned for the same reason as cibuildwheel above: this builds the sdist
+      # that is published alongside the wheels.
+      - run: pip install build==1.6.0
       - run: python -m build --sdist
       - uses: actions/upload-artifact@v7
         with:

CHANGELOG.md

@@ -97,6 +97,31 @@ against, and semantic-release manages only the **patch** component.
   - `test_a_copy_does_not_pin_its_source` — asserts the aliasing/copying split
     directly, via refcount: a view increfs its parent, a copy does not.
 
+### Changed
+
+- **The build toolchain is pinned**: `cibuildwheel==4.2.0` and `build==1.6.0` in
+  `wheels.yml`, and `scikit-build-core>=0.10,<2` in `pyproject.toml`. Only the
+  last is user-visible, and only for a source install.
+
+  These three build, repair, test and publish every wheel, and all three were
+  unbounded — the same exposure that took ruff, nanobind and GitPython out. It
+  had already happened silently: **cibuildwheel 3.x → 4.x and scikit-build-core
+  0.x → 1.0 both crossed under the open bounds**, so the wheels published as
+  5.10.2 were built by tooling nobody selected. They worked; nothing chose them.
+
+  `scikit-build-core` is capped at the major rather than exact-pinned, since
+  patch fixes to a build backend are worth taking automatically and a major is
+  not. It also supplies the CMake that runs (4.4.2 as of this writing), which is
+  a constraint arriving from a dependency the project never names.
+
+  Deliberately **not** pinned: `numpy` stays `>=1.24`. That would normally be the
+  ABI trap, but there are no numpy C headers anywhere in the extension —
+  `nb::ndarray` goes through DLPack and the buffer protocol — so numpy is a
+  stub-generation build dep and a runtime import with no compile-time coupling.
+  The ecosystem test dependencies (torch, jax, pandas, scikit-learn) are also
+  left floating pending a decision on what that job is for; see
+  [#90](https://github.com/stillwater-sc/mtl5-python/issues/90).
+
 ### Fixed
 
 - **nanobind capped below 3.0** (`nanobind>=2.0,<3`), which unbreaks every wheel

pyproject.toml

@@ -32,7 +32,12 @@
 # nanobind 3.0.0 broke every build the day it released precisely because there
 # was none.
 requires = [
-    "scikit-build-core>=0.10",
+    # Capped at the major. scikit-build-core is the PEP 517 backend -- it drives
+    # every wheel build and supplies the CMake that runs (4.4.2 as of this
+    # writing). The 0.x -> 1.0 major already crossed under the open bound
+    # without anyone selecting it. Capped rather than exact-pinned because patch
+    # fixes to a build backend are worth taking automatically; a major is not.
+    "scikit-build-core>=0.10,<2",
     "nanobind>=2.0,<4",
     "numpy>=1.24",
     "packaging>=22",