Use cibuildwheel to automatically build all the wheels, avoid manual builds

[BishopWolf]

This PR is intended to open a discussion to address the issue #928

This changes current wheel generation. CONFIRM AND APROVE BEFORE MERGE!!!

• Windows is producing all the wheels now, fully auto using delvewheel
• Linux is producing all the wheels now, fully auto
• Macos is producing all the wheels now, fully auto
• All Tests passing
• Add Qt to Windows. Will be made in another PR
• cache brew for macos, this will reduce build time. Will be made in another PR

Current status:

• Supported ARCHS:
  • Windows x86_64 (NO ARM !)
  • Linux x86_64 ; ARM
  • MacOS intel ; ARM64
• Supported Python: 3.10 up to 3.14; except macos intel which has no python 3.14 support
• Currently we build one wheel per python version and per system.
• The selection of python versions is manual. But we start with a pinned version, then we let CIBW build the correct wheel for the desired version.
• Total build time averages 45 minutes before tests. Each build takes 16 minutes preparation and around 15 minutes build, but not all start at the same time.

Possible improvements:

• We could let cibuildwheel select the python version automagically. This is scalable in time as cibuildwheel knows which python versions correspond to each system.
• We could use a single system to build the tagged wheels, this will simplify a lot the action scripts. Even for novis builds you can just use python 3.12 to build the wheel for 3.9 if needed.
• Total build time will average 50 minutes dropping unneeded python versions. 16 minutes preparation ONCE and 10 minutes per build for each python version. In the case of macos, the delocation also takes 10 more minutes, its almost instantaneous in linux and windows.

[BishopWolf]

@tbaudier right now we only support these os
os: [ubuntu-24.04, macos-15, windows-2025]

however, to support more we just need to add them, they will be built by default
os: [ubuntu-24.04, ubuntu-24.04-arm, macos-15, macos-15-intel, windows-2025, windows-11-arm]

ALSO: No need to further worry about python version, the variable requires-python = ">=3.9" defines everything automagically

[BishopWolf]

@tbaudier This is clean and ready, you can merge if approved

[tbaudier]

Thank you, First we want to do the release and then I will have a look to your PR

[BishopWolf]

@tbaudier windows is fully automatic now.

[BishopWolf]

Windows and Linux build in less than 10 minutes per python version
Macos needs on average 16 minutes, this should be addressed

[BishopWolf]

@tbaudier we can leave the one wheel per python version if you think the builds are too slow.
For me they are fine like this as cibuildwheel is automagically selecting the correct python versions for each system.
The change is not that hard to do, just add back the python matrix and add this to each script (it will work on all of them)

if [[ ${MATRIX_PYTHON_VERSION} == "3.10" ]]; then
  export CIBW_BUILD="cp310-*"
elif [[ ${MATRIX_PYTHON_VERSION} == "3.11" ]]; then
  export CIBW_BUILD="cp311-*"
elif [[ ${MATRIX_PYTHON_VERSION} == "3.12" ]]; then
  export CIBW_BUILD="cp312-*"
elif [[ ${MATRIX_PYTHON_VERSION} == "3.13" ]]; then
  export CIBW_BUILD="cp313-*"
elif [[ ${MATRIX_PYTHON_VERSION} == "3.14" ]]; then
  export CIBW_BUILD="cp314-*"
fi

EDIT: I can see it's definitely faster, i'll push the changes

[BishopWolf]

@tbaudier I can add back python 3.10 support for both windows and macos, it is building fine for me.

[BishopWolf]

Homebrew/actions#829 (comment)

[BishopWolf]

brew qt should be fine for all macos versions accordingly to https://formulae.brew.sh/formula/qt. the cache should handle it

[BishopWolf]

I have rebased the last working commit to current master. I can add the intended modifications in a different PR.

Current issues:
When adding QT in windows : the virtual machine can't find the conda location. https://github.com/BishopWolf/opengate/tree/windows-qt6

When using homebrew cache in mac : cibuildwheel can't find system python

[BishopWolf]

@tbaudier @dsarrut @nkrah Let me know when are you available to discuss this PR

[tbaudier]

Hello @BishopWolf can you rebase the PR please, specially with the new version tag, your commit c616243 should be removed. Then I will test the visualization part. Thank you

[BishopWolf]

@tbaudier I have also tested in a macos-15-intel I have, and it builds fine with passing tests on python 3.12

[tbaudier]

Thank you, I will do some test because I have a macos intel to check the visualisation. I let you know

[BishopWolf]

@tbaudier
for the ci in macos intel and windows arm we can set miniconda with python 3.12, i don't think there's a higher version supported

EDIT: Confirmed for these OS: Miniconda 26.3.2-2
Apr 28, 2026 https://www.anaconda.com/docs/getting-started/miniconda/release/26.x
Available Python versions: 3.13.13, 3.12.13, 3.11.15, 3.10.20

So no python 3.14

[BishopWolf]

In my macos intell brew can install qt, even in the ci it could. But somehow delocate can't find it. This is weird, i'll revert to conda qt

[BishopWolf]

@tbaudier windows arm is not suppported by conda https://repo.anaconda.com/miniconda/
either we find a replacement or we drop the support for it

[BishopWolf]

@tbaudier everything is ready to merge. You can do your tests

[BishopWolf]

@tbaudier I really think the issue of brew qt is that geant4 was compiled with conda qt and it doesn't like the brew one.

Either we recompile geant4 with brew qt as in macos arm64 or we keep conda for qt in intel which adds extra maintenance burden

To keep conda just delete the last two commits

[BishopWolf]

@tbaudier since I will change qt installation in another PR, it makes no sense to have it here. I have reverted the last two commits.