search

UCL-ARC / python-tooling

Python package template for new research software projects
http://github-pages.arc.ucl.ac.uk/python-tooling/
MIT License
39 stars 2 forks source link

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

Closed paddyroddy closed 4 months ago

paddyroddy commented 5 months ago

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 commented 5 months ago

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

paddyroddy commented 5 months ago

Should we drop 3.9 altogether due to NEP29?

dstansby commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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

image
matt-graham commented 5 months ago

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 commented 5 months ago

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

giordano commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

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