Context
The wheel build/publish pipeline (.github/workflows/python-publish-pypi.yml) is hand-rolled: a (os × python-version) matrix that sets up miniconda, creates a conda env with the build toolchain (compilers, meson-python, ninja, cython, pybind11, ...), runs pip wheel, then a repairwheel step to make the wheels self-contained.
This works — 3.3.7 wheels are self-contained on all platforms (the all-platform repairwheel step bundles libomp on macOS and the MinGW runtime DLLs on Windows). So this is a maintainability idea, not a correctness gap.
Observation
meshpy (our mesh dependency) builds its wheels with cibuildwheel, which provides — off the shelf — the Python×platform build matrix, isolated build environments, and wheel repair (auditwheel on Linux, delocate on macOS, delvewheel on Windows). Our pipeline re-implements much of that by hand. Migrating could shrink the custom CI and get repair/matrix handling "for free."
Caveats / open questions
Suggested first step
Determine feasibility by trying to build the extensions with MSVC on Windows (e.g. a scratch cibuildwheel run). If the code compiles cleanly under MSVC, a cibuildwheel migration becomes attractive; if not, the current conda+repairwheel approach stays the pragmatic choice.
Context
The wheel build/publish pipeline (
.github/workflows/python-publish-pypi.yml) is hand-rolled: a(os × python-version)matrix that sets up miniconda, creates a conda env with the build toolchain (compilers,meson-python,ninja,cython,pybind11, ...), runspip wheel, then arepairwheelstep to make the wheels self-contained.This works — 3.3.7 wheels are self-contained on all platforms (the all-platform
repairwheelstep bundleslibompon macOS and the MinGW runtime DLLs on Windows). So this is a maintainability idea, not a correctness gap.Observation
meshpy (our mesh dependency) builds its wheels with cibuildwheel, which provides — off the shelf — the Python×platform build matrix, isolated build environments, and wheel repair (
auditwheelon Linux,delocateon macOS,delvewheelon Windows). Our pipeline re-implements much of that by hand. Migrating could shrink the custom CI and get repair/matrix handling "for free."Caveats / open questions
CIBW_BEFORE_ALL/pip and OpenMP would need providing (e.g.brew install libompon macOS, delocate to bundle it).gcc_win-64) and bundle the MinGW runtime viadelvewheel. cibuildwheel defaults to MSVC on Windows → wheels would depend only on the universally-present VC redistributable (more robust, and it sidesteps the MinGW-runtime-bundling entirely — the exact thing that bit meshpy, see Windows wheels are not self-contained: _internals.pyd needs unbundled MinGW runtime DLLs (libstdc++-6, libgcc_s_seh-1) inducer/meshpy#150 / Bundle MinGW runtime DLLs into Windows wheels (delvewheel) inducer/meshpy#151). The prerequisite is that ANUGA's C/C++ extensions compile under MSVC.Suggested first step
Determine feasibility by trying to build the extensions with MSVC on Windows (e.g. a scratch cibuildwheel run). If the code compiles cleanly under MSVC, a cibuildwheel migration becomes attractive; if not, the current conda+repairwheel approach stays the pragmatic choice.