tests on github action always use Python 3.13 on MacOS

[hugobuddel]

E.g. https://github.com/AstarVienna/HowManyBloodyPhotons/actions/runs/12975778044/job/36187246540?pr=17

Offline tests / macos-latest, 3.11

Run actions/setup-python@v5
  with:
    python-version: 3.11
    check-latest: false
    token: ***
    update-environment: true
    allow-prereleases: false
Installed versions
  Successfully set up CPython (3.11.9)

but then

installing poetry from spec 'poetry==1.8.3'...
done! ✨ 🌟 ✨
  installed package poetry 1.8.3, installed using Python 3.13.1
  These apps are now globally available
    - poetry

and

 Creating virtualenv howmanyphotons-qbZ0wNV1-py3.13 in /Users/runner/Library/Caches/pypoetry/virtualenvs
Installing dependencies from lock file

and

  Backend subprocess exited when trying to invoke get_requires_for_build_wheel
  
  Traceback (most recent call last):
    File "/Users/runner/.local/pipx/venvs/poetry/lib/python3.13/site-packages/pyproject_hooks/_in_process/_in_process.py", line 389, in <module>
      main()
      ~~~~^^

This does not happen for ScopeSim, because Scopesim explictly disaalows 3.13: python = ">=3.10, <3.13" and therefore goes ahead and uses the Python mentioned in the matrix:

 The currently activated Python version 3.13.1 is not supported by the project (>=3.10, <3.13).
Trying to find and use a compatible version. 
Using python3 (3.11.9)
Creating virtualenv scopesim-QO9Zeqha-py3.11 in /Users/runner/Library/Caches/pypoetry/virtualenvs
Installing dependencies from lock file

@teutoburg do you have an idea how to solve this?

[teutoburg]

Seems to be this: abatilo/actions-poetry#72

[hugobuddel]

Thanks. I had my reluctance of moving to v4 of actions-poetry (AstarVienna/DevOps#43) but apparently v3 is already problematic. What a mess this is... Maybe we should revert to actions-poetry v2?

The interesting thing is that only HowManyBloodyPhotons is affected because there we do not define an upper limit for the Python version, so poetry is fine with using 3.13. But in the other projects it is not allowed to use 3.13 so it finds the Python installed by the python-setup and uses that.

But all our packages will be affected once we add support for Python 3.13.

[teutoburg]

Perhaps we could try the workaround mentioned in this comment. I'm not sure what's the advantage of using this action instead?

[hugobuddel]

Yeah sure, we could ditch using this action altogether

[teutoburg]

Yeah sure, we could ditch using this action altogether

Let's maybe try that in a DevOps branch and then use that branch here for the tests to see how that goes?