This is the current blocker

Traceback (most recent call last):
  File "/Users/runner/work/opengate/opengate/core/setup.py", line 7, in <module>
    import setuptools
ModuleNotFoundError: No module named 'setuptools'
Error: Process completed with exit code 1.

@tbaudier your docker image of opengate_core does not support python 3.14

Status: Downloaded newer image for tbaudier/opengate_core:v11.3.2
+ echo cp314-cp314
cp314-cp314
+ cd /home/core/
....
/home/.github/workflows/createWheelLinux.sh: line 13: /opt/python/cp314-cp314/bin/pip: No such file or directory
Error: Process completed with exit code 127.

Another issue, cmake minimum should be 3.10 as anything older has no support already

# File [opengate/core/CMakeLists.txt:l8]
cmake_minimum_required(VERSION 3.5.0)

@tbaudier I don't understand the ci build wheel for macos. Why forcing python3.12?
isn't it better to take the version from the build matrix?

Hello @BishopWolf
Thank you for all the work

• for unix, the docker image will be updated sooner with the new G4 version. And in that image python 3.14 will be included
• for mac, the python used to compile opengate_core is the python installed by actions/setup-python. The line containing the python installed by brew was a remnant line from a previous bug on Intel machines of Github actions. Maybe the line could be removed
• For windows, to support python 3.10 is more important than support 3.14 (https://w3techs.com/technologies/history_details/pl-python/3)

@tbaudier

Theoretically I don't need to modify anything else for Unix; just wait for the new docker image, everything should work fine.

I will try removing the Python version for macOS. I think, however, it is required based on the build logs.

Everything should work for Windows now. I found a way to discriminate the ci_build_wheel version based on the Python version

@tbaudier I see that you have support for Python 3.6 up to 3.9 in the docker image; this shall be removed to decrease the size.

ls -l /opt/python/
lrwxrwxrwx 1 root root 30 Feb 23  2025 cp310-cp310 -> /opt/_internal/cpython-3.10.16
lrwxrwxrwx 1 root root 30 Feb 23  2025 cp311-cp311 -> /opt/_internal/cpython-3.11.11
lrwxrwxrwx 1 root root 29 Feb 23  2025 cp312-cp312 -> /opt/_internal/cpython-3.12.9
lrwxrwxrwx 1 root root 29 Feb 23  2025 cp313-cp313 -> /opt/_internal/cpython-3.13.2
lrwxrwxrwx 1 root root 35 Feb 23  2025 cp313-cp313t -> /opt/_internal/cpython-3.13.2-nogil
lrwxrwxrwx 1 root root 29 Feb 23  2025 cp36-cp36m -> /opt/_internal/cpython-3.6.15
lrwxrwxrwx 1 root root 29 Feb 23  2025 cp37-cp37m -> /opt/_internal/cpython-3.7.17
lrwxrwxrwx 1 root root 29 Feb 23  2025 cp38-cp38 -> /opt/_internal/cpython-3.8.20
lrwxrwxrwx 1 root root 29 Feb 23  2025 cp39-cp39 -> /opt/_internal/cpython-3.9.21
lrwxrwxrwx 1 root root 33 Feb 23  2025 pp310-pypy310_pp73 -> /opt/_internal/pp310-pypy310_pp73
lrwxrwxrwx 1 root root 33 Feb 23  2025 pp311-pypy311_pp73 -> /opt/_internal/pp311-pypy311_pp73

@tbaudier Do you think it is relevant to start supporting non-GIL python versions? starting with 3.13t. I could add it to this PR.

@tbaudier Do you think it is relevant to start supporting non-GIL python versions? starting with 3.13t. I could add it to this PR.

For me, if no one use/need that version, for the moment it's not necessary