I’d add two more potential action items:
- Add buildbot testing for recent Python versions. If I understood correctly, it sounds like this currently happens only downstream.
- Consider integrating static analysis checking for the minimum Python version in CI (see the vermin project referenced above). I expect this will reduce the cost of supporting older Python versions by shortening the feedback cycle, and address concerns about installing EOL Python locally (which is indeed not something I would expect anyone to do).
Create RFC to have seperate versions for build and bindings, with process for updating binding version used.
I’d qualify “bindings” here specifically to “MLIR Python bindings”. While we also have other Python bindings, the MLIR Python bindings are somewhat unique in how rapidly moving they are, and in how they have other bleeding-edge dependencies.
For example, if I understood comments above correctly, making the LLDB Python bindings require something newer than Python 3.9 would be problematic for LLDB on macOS.