support python 3.14

[Joerg Henrichs (hiker)]

Trying to fix python 3.14, see #510 for details.

[Joerg Henrichs (hiker)]

Sam Clarke-Green (@t00sa) , I don't fully understand the cui/aeguments.py file, so please check that my change there was ok.

I also fixed a small test bug (some tests would fail if you have a working mpif90 in your path, see conftest.py)

[Matthew Hambley (MatthewHambley)]

In general I am not in favour of code under test being different from deployed code but I think that is a problem we can postpone to later.

[Matthew Hambley (MatthewHambley)]

How does this change relate to Python v3.14?

[Joerg Henrichs (hiker)]

As I've written:

I also fixed a small test bug (some tests would fail if you have a working mpif90 in your path, see conftest.py)

Not directly related, except my python 3.14 environment happened to have mpif90 and caused test failures.

[Joerg Henrichs (hiker)]

In general I am not in favour of code under test being different from deployed code but I think that is a problem we can postpone to later.

I totally agree with that, I only did it because of the existing comment acknowledging the line, and so I thought it would be acceptable for now (the commit that introduced the change only mentions something about making it aware of ifort or so. nothing really helpful as far as I could see).

I actually did try a few other things, but no real success. The problem seems to be that we have two level of child processes (multiprocessing spawn for the steps, then we run compiler etc), and Copilot told me (and admittedly I didn't check, but this is pretty much what I see):

pytest‑subprocess has never supported mocking subprocesses inside child processes.
Python 3.14’s stricter import/pickle rules make this limitation more visible.

E.g. we fake:

        fake_process.register(['sfc', '--version'], stdout='1.2.3')
        fake_process.register(['sfc', fake_process.any()])

and then call compile_pass, which does run_mp and then checks if the compiler is available (first fake process), and then the actual compilation. So even if we set the compiler to be available (avoiding the first fake process), we are still stuck with the second one :(

More googling might have given me a different approach: I tried before to switch multiprocessing back to fork, but that somehow didn't work (I believe the complication is to find where multiprocessing is imported first). But what seems to work:
in steps/__init__.py (run_mp):

    if config.multiprocessing and not no_multiprocessing:
        ctx = multiprocessing.get_context("fork") 
        with ctx.Pool(config.n_procs) as p:
            results = p.map(func, items)
    else:
        results = [func(f) for f in items]

    return results

I.e. explicitly switching from the new forkserver back to fork. I don't know enough about the details of this change to know if this is acceptable, but it feels like a better solution - at least then tests and 'real' code are consistent. But using fork might have disadvantages (i.e. there must be a reason why the python default multiprocessing was switched).

Let me know what you prefer me to do (and if I should leave the line in the build config in that disables subprocessing in case of debugging)?