Change CI to either use `macos-13` or drop `3.9` support

[paddyroddy]

Describe the Bug

See bug described here https://github.com/actions/setup-python/issues/850, essentially macos-latest now represents ARM mac 😱

To Reproduce

Use macos-latest in conjunction with python versions <3.10

Expected Behaviour

Actual Behaviour

Additional Context

- Cookiecutter version:
- Operating system: macos
- Python version: 3.9

[dstansby]

My vote would be to have runs with macos-13 + {3.8, 3.9} and macos-latest + {3.10, 3.11, 3.12}.

[paddyroddy]

Should we drop 3.9 altogether due to NEP29?

[dstansby]

I can't remember if we ever discussed NEP29, but I'd currently advocate for supporting all supported Python versions instead of following NEP29. Motivation is we don't want to limit this to just numpy/scientific python specific packages, so we shouldn't follow NEP29 which is scientific python specific.

[paddyroddy]

I've had a look and I don't think we've discussed it. I've tended to follow it, but I can see arguments either way.

[paddyroddy]

There's also SPEC 0 which @p-j-smith highlighted. I suspect most of our users will be doing scientific work, I assume.

[matt-graham]

I think choosing to follow something like NEP29 or SPEC0 to follow make sense to avoid having to spend too long debating and thinking about what versions to support in the long term and because I think there is value in keeping the list of versions we support relatively short both from the perspective of being able to use newer language features internally and encouraging users to use relatively recent Python versions (which I'd say is part of the good practice we want to promote).

I agree with @dstansby we don't necessarily just want to limit to just scientific Python specific packages, but I also think that following the scientific Python ecosystem recommendations doesn't limit us to use in those settings unless there is similar set of guidelines in other communities which specifically recommend something else (which as far as I'm aware there isn't?). I also think the point made in SPEC0 that having longer support cycles is no longer so important given the much wider use of virtual environments is a good argument in favour of keeping our supported version list short.

So I would vote for choosing one of SPEC0 or NEP29 to adopt (I was only previously aware of NEP29 but happy to go with SPEC0) and on that basis then dropping 3.9 support as I think its out of suggested support window of both(?).

[dstansby]

I opened an issue at https://github.com/UCL-ARC/python-tooling/issues/362 to discuss Python version support.

[giordano]

If the motivation is only the actions/setup-python currently failing, why don't you explicitly set the architecture to x64 and keep testing older versions of Python?

[paddyroddy]

If the motivation is only the actions/setup-python currently failing, why don't you explicitly set the architecture to x64 and keep testing older versions of Python?

It's not the only motivation IMO. I hadn't checked NEP29, so hadn't realised 3.9 was 💀

[p-j-smith]

I would lean towards testing on all Python versions that still get security patches, and let users decide if they want to follow NEP29 / SPEC0, but happy to go with the crowd