Comment (by Gabriele Bozzola):

Let me add this as a discussion item, though really (my personal opinion) the authors should spend time on coming up with solutions. Part of having things
included in the ET means that they must make some effort in keeping things working with the ET. If they want to do whatever they want then having it in a toolkit used by many and with a statement of supported clusters then they should not include it. "it works for me" is not good enough anymore, it has to work for others.

Only two in the set {kuibit supports Python 3.6, kuibit supports Python 3.11, the dependency tree of kuibit is vetted and verified consistent and compatible}, so I decided to raise the minimum version required because depends heavily on the NumPy ecosystem, which has a tight support schedule and sometimes introduces breaking changes that ripple through all the downstream packages (for example, in 1.20, NumPy deprecated the names np.int, np.float and so on).

I presented the community with the statement that the next version of kuibit will depend on Python>=3.8, and the problem I raised is “what do we want to do in this situation?”

Among the options are:

• We require Python 3.8 and build it when it is not available
• We require Python 3.8 and claim the clusters that don’t have it “not supported”
• We maintain both kuibit 1.3.X and 1.4.X
• We require as minimum ET dependency Python 3.7 and reject this kuibit update.

Note that the latest Fedora (one of the supported machines) defaults to Python 3.11, so kuibit 1.3.6 cannot be installed there.

That’s why I feel this is more of a policy issue than a technological one (that I could solve myself).

‌

--
Ticket URL: https://bitbucket.org/einsteintoolkit/tickets/issues/2696/update-kuibit-to-140