Python 3.8 end of life

[fabcor-maxiv]

Python 3.8 has reached its end of life.

How do we want to handle this?

[fabcor-maxiv]

I happened to be thinking about this now because I wanted to update our tooling, starting with the pre-commit hooks, but encountered issues. I realized it is because a bunch of tools have already dropped support for Python 3.8, for example pre-commit and black. This is manageable, but annoying. We have pinned a whole bunch of things, so that is good, this should limit the amount of cases where things start breaking because a dependency dropped support for Python 3.8.

Anyway, do we have a general plan of how we want to handle Python 3.8's end of life?

[fabcor-maxiv]

For example here, I ran pre-commit autoupdate at first, but then had to pin to some earlier versions because of Python 3.8 being dropped.

[marcus-oscarsson]

I think we can also drop Python 3.8 but we should have a look at the deployment survey to get an idea of how many sites that are still using Python 3.8 and if it would be a blocking issue if we where to drop it. We should bring it up on our next meeting. We have to, in my opinion, sooner or later drop the Python 3.8 support.

In the mean time, to all of those still using Python 3.8. Please let us know and let us know what you think.

[rhfogh]

While we are at it, could we consider moving to a newer version than 3.9? The fewer changes the better. Ideally 3.13 I guess, but as far as we can go. What would be the blocker?

[fabcor-maxiv]

we should have a look at the deployment survey to get an idea of how many sites that are still using Python 3.8

I just checked and the questionnaire did not ask for Python version explicitly, so most answer sheets do not say it.

In the mean time, to all of those still using Python 3.8. Please let us know and let us know what you think.

I think the question should be a bit more precise. We want to know which setup is both on Python older than 3.9 AND living on the edge of what is on GitHub. If setups have Python 3.8 or older, but live with an older version of MXCuBE (and no intention to catch up with the upstream develop branch) then for those setups it should also not matter if we drop Python 3.8.

[fabcor-maxiv]

If I am not mistaken, at MAXIV in the software teams in general we aim to have support for Python versions 3.8, 3.10, and 3.12. But for MXCuBE, we could in principle do our own thing and support 3.13 with some additional effort from MX software team if it makes sense.

[marcus-oscarsson]

While we are at it, could we consider moving to a newer version than 3.9? The fewer changes the better. Ideally 3.13 I guess, but as far as we can go. What would be the blocker?

In principle yes but we just have to make sure that no site has some other requirements that force them to use a particular version of Python, and if its the case how to manage that. For ESRF from 3.10 and up would be fine.

[rhfogh]

@fabcor-maxiv
There is no particular reason to spend extra resources to support 3.13. I was just thinking 'if we can, let us jump multiple versions to delay having to do this again', so let us see what lowest common denominator the sites can come up with.