PyPI Cantera for Python 3.12

[corykinney]

I figured this would be a better place to open a discussion than the main repository. I think it would be beneficial to always try to update the latest Cantera release on PyPI to support the latest Python versions as long another Cantera release isn't imminent. Building from source is always an option, but for projects that have Cantera as a dependency in CI/CD test cases, having the latest pip installable package not support the latest Python can be a limiting factor.

It looks like the changes to support Python 3.12 were fairly minimal, unless I'm missing something I see these related changes, although some of the contained commits are just internal CI:

• Add Python 3.12 post-merge-test cantera#1612
• mods to enable python3.12 cantera#1604
• [scons] Bump python_max_p1_version to 3.13 cantera#1648

Would there be any issues with cherry picking the necessary commits onto a branch from the official 3.0.0 release tag and uploading the package to PyPI? I wish this was something I could help with preparing, but obviously it would require one of the developers to perform. I suppose the other option would be a 3.0.1 release, but it seems that Cantera avoids patch versions and opts for occasional minor versions.

[bryanwweber]

Hi Cory, thanks for posting this. Unfortunately, doing a release (which would be required to push things to PyPI given our CI setup) is quite a bit of manual work even with all we've automated. So I don't think we'd be willing to release 3.0.1. My understanding is that 3.1 is not too far off.
As far as CI/CD is concerned, you should be able to build the wheel for Python 3.12 from the sdist on PyPI. None of the changes you listed are actually required for Cantera to function, with the exception of user-defined reaction rates won't work without #1604. If there are any problems building from the sdist, please do let me know and I can look into them hopefully!

[corykinney]

@bryanwweber Thanks for the response! I have no problem building the wheel for 3.12 from the sdist on PyPI in my development environment, the challenge I see is that doing so requires the boost headers to be installed on the machine and an environment variable to be set. Using something like GitHub actions, I'm not sure how to accomplish the build to run Python 3.12 for a package that depends on Cantera. Do you have any ideas?

[bryanwweber]

Hi @corykinney, it shouldn't be a problem to install Boost headers on a GH actions runner. You can find several examples of this for all three major platforms in the main Cantera CI configuration. And if the headers are in the system standard location, you shouldn't need the environment variable, but if you do you can set that too in the configuration

[corykinney]

Hi @corykinney, it shouldn't be a problem to install Boost headers on a GH actions runner. You can find several examples of this for all three major platforms in the main Cantera CI configuration. And if the headers are in the system standard location, you shouldn't need the environment variable, but if you do you can set that too in the configuration

Okay, I found the boost header installation in the main Cantera CI now, assuming this what you were referring to. This should work as a band-aid for my CI/CD purposes until the next Cantera release.

However, I thing this brings up the question - is it possible to decouple the PyPI workflow from the main CI so that it can be run for existing releases when new versions of Python are released? It's one thing to modify CI to install boost headers, but it would be difficult to easily distribute a tool built on top of Cantera. Either the end user would also have to install boost headers if they want to use the latest version of Python, which might be confusing for less savvy developers, or that tool would also have to be version locked to whatever version of Python was out when the last Cantera version was released.

While decoupling it would add one additional step to publishing new Cantera releases, I think the flexibility gained would be worthwhile. Otherwise, Cantera 3.1 might come out soon and remedy the issue, but only temporarily, as Python 3.13 is already planned for release at the beginning of October. I'm not trying to be demanding, I'm just interested in making working with Cantera as frictionless as possible and I'm curious to hear the development team's thoughts!

[speth]

is it possible to decouple the PyPI workflow from the main CI so that it can be run for existing releases when new versions of Python are released?

These workflows are decoupled -- the PyPI packages are built from this repo: https://github.com/Cantera/pypi-packages/. The problem is that in general, the current Cantera release isn't likely to be compatible with a future Python release without a few modifications.

I'm just interested in making working with Cantera as frictionless as possible and I'm curious to hear the development team's thoughts!

My recommendation for users would be to just use the latest version of Python that's fully supported by all their dependencies, Cantera included. I don't think being on the absolute latest version of Python is really that critical.

[corykinney]

@speth Understood! Hopefully I didn't come off as demanding, I just wanted to check and see if it was feasible, which it doesn't sound like it is! Thanks for taking the time to explain.