Drop support for Python 3.8, support Python 3.12?

[agriyakhetarpal]

NumPy>=1.26 and SciPy>=1.11 support Python 3.9+ now and already have wheels for Python 3.12. The blocker should be CasADi, which might have a new release soon because the pre-release is available. In any case, we should be able to drop Python 3.8 support at this time and 3.12 can wait

[Saransh-cpp]

I don't think we should drop support for Python 3.8 unless PyBaMM breaks on 3.8 or 3.8 reaches end-of-life.

We can actually start testing PyBaMM on 3.12 in the CI. IIRC, pybind11 has already migrated to Python 3.12, and we can fetch CasADi's nightly wheels in the 3.12 job.

[agriyakhetarpal]

Yes, it would be good to try supporting Python 3.12, which comes tomorrow. xarray doesn't run CI against 3.12 yet, but they list their Python dependency as >=3.9. I think we should be fine with using the nightly wheels for CasADi, should we let the optional dependencies catch up later?

I don't think we should drop support for Python 3.8 unless PyBaMM breaks on 3.8 or 3.8 reaches end-of-life.

That makes sense, I just checked and Python 3.8 EOL is in October 2024, so we have just about a year to remove it

[Saransh-cpp]

We should only build and ship pybamm wheels once every dependency works, but testing pybamm (just with the required dependencies) in the CI should be good.

(release candidates of 3.12 have been available on GH Actions for quite some time now)

[agriyakhetarpal]

Good idea, we could also do these checks in the nightly releases when ready (#3251) since it would help catch errors and deprecations early

[Saransh-cpp]

Copying from slack -

https://scientific-python.org/specs/ - like PEPs but for the Scientific Python ecosystem. I think we should follow them to stay up-to-date with other libraries.

The first SPEC suggests removing Python 3.9 support by the end of this year, but I’m not sure if we should do that 😬

[agriyakhetarpal]

There are a lot of interesting things available in the Scientific Python ecosystem, perhaps we should also try using sp-repo-review? I guess this would be better off as a separate issue, please let me know if I should open one

[Saransh-cpp]

Some of the failing checks in repo review are intentional from our end (for example - we removed codespell, prettier, and isort as pre-commit hooks because they were doing more harm than good), and some of them are potential GSoC projects (for example - pybamm wide typing hints), but yes an issue to track repo review's suggestions would be nice. We could either implement the suggestions, discard them, or mark them as implemented.

PS: we weren't using repo review before because it was Scikit-HEP specific, but now they've moved it to Scientific Python, which is nice!

[agriyakhetarpal]

Makes sense. I will run the tool locally and see what we are missing, I cannot get it to to work inside the browser at all for some reason. There has been some discussion about a PR for adding type hints to PyBaMM models after they have been serialised in #3397 (or they were probably for the expression tree: not sure) in the developer meeting yesterday

[pipliggins]

Makes sense. I will run the tool locally and see what we are missing, I cannot get it to to work inside the browser at all for some reason. There has been some discussion about a PR for adding type hints to PyBaMM models after they have been serialised in #3397 (or they were probably for the expression tree: not sure) in the developer meeting yesterday

I've been going through and adding type hints for the expression trees yes (they're more of a by-product from trying various methods for serialisation) - I'll make a PR asap for those.

[agriyakhetarpal]

casadi now supports Python 3.12 (https://github.com/casadi/casadi/releases/tag/3.6.4) which checks all four of our core dependencies. I installed all dependencies with Python 3.12 locally without issues, except for [jax] (which will now require bumping the versions) and [odes] (I see that numpy removed distutils with Python 3.12+ which broke the wheel building process – I can file an issue upstream requesting for a fix).

@Saransh-cpp: should we try for Python 3.12? We can still keep Python 3.8 as discussed above. I was supposed to work on #3443, which I can then close in the same PR to avoid merge conflicts. In any case, it will be merged only after the stable release, so we have a lot of time to look into any failures that occur.

[Saransh-cpp]

should we try for Python 3.12? We can still keep Python 3.8 as discussed above.

Yes! We can add a note in the docs about optional dependencies not yet supported for Python 3.12.

and [odes]

Ah, I remember the maintainers of scikits.odes were waiting for NumPy's migration to meson to stop using numpy.distutils, but the repository is inactive. See my old PR bmcage/odes#137 for some discussion on this. Creating an issue there should be good.