Decide on a Python version support policy

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

Decide on a Python version support policy #362

Open dstansby opened 4 months ago

dstansby commented 4 months ago

What needs to be done?

It would be good to decide and document which versions of Python to support. The two options here seem to be:

All currently supported Python versions (currently 3.8 - 3.12)
All Python versions supported by Scientific Python Ecosystem Coordination 0 (currently 3.10 - 3.12)

dstansby commented 4 months ago

I'm happy for either - I see the arguments for only supporting newer versions (https://github.com/UCL-ARC/python-tooling/issues/359#issuecomment-2077351878), but also don't think there would be much more burden in supporting older but-still-security-patched versions.

samcunliffe commented 4 months ago

Half-vote for keeping 3.9 🗳️. (I guess that's option 1.5 🙃 )

dstansby commented 4 months ago

I'm 👎 👎 having an ad-hoc approach where we decide a list of versions we support on a rolling basis, instead of following an existing policy that decides for us.

samcunliffe commented 4 months ago

~~Wait, 3.8 is EOL, no?~~

Nope. 3.8's EOL is 2024-10 so option 1 will become what I voted for very soon.

paddyroddy commented 4 months ago

I vote 2️⃣

dstansby commented 4 months ago

I'm coming round to 1️⃣ , because I don't think it is much more effort to support more Python versions, and we do work on some projects in ARC that aren't within the scientific python ecosystem (I'm thinking web projects, but maybe there's others?)

dstansby commented 4 months ago

Those advocating for 2️⃣ , what are your reasons?

paddyroddy commented 4 months ago

For me, a few reasons:

The green reason, inevitably CI will have to run more
Missing out on new features of the language - you'll get them eventually, but nice to get them quicker
Missing out on potential speed gain, for example Python 3.11 was 10-60% faster than Python 3.10 - again you'll get it eventually, but once the min version is 3.11 then you benefit quicker
Supported by big communities, SPEC 0 is endorsed by ipython, networkx, numpy, scikit-image, scipy, xarray, zarr
New libraries may not be built to support older Python versions, say 3.10 was the newest one when it came out. It may not support older versions.

dstansby commented 4 months ago

The green reason, inevitably CI will have to run more

If you do the numbers I think this is very small number compared to e.g., flying to conferences or on holiday or embodied carbon of hardware or electricity usage of a large simulation code. I once etimated that Matplotlib uses ~25 kg/month [png link], and they must be running orders of magnitude more CI than us.

I buy the rest of the arguments though. I think @matt-graham was also pro SPEC 0, so perhaps we give @samcunliffe a bit to explain

Half-vote for keeping 3.9

from above, and then unless there's a compelling reason go with SPEC 0?

samcunliffe commented 4 months ago

My vote was a soft 1, but very soft. Mostly web/dashboard/other.

If the majority want 2, let's go for it. Less GHA minutes also has cost implications if our users have nonpublic repos. And 🌱 is a good argument.

dstansby commented 4 months ago

👍 I'll leave this open until we document the decision, and merge https://github.com/UCL-ARC/python-tooling/pull/360