Question(s) about the migration to cppjit

[tmadlener]

After having stumbled over a few smaller issues related to the switch from cppyy to cppjit (see CppInterOp based cppyy migration by aaronj0 · Pull Request #21261 · root-project/root · GitHub, I was wondering whether there is some publicly available plan on that migration (I might have simply missed it and would appreciate a pointer). Specifically, I would be interested in

• a timeline
• which parts are expected to be fully transparent, and which ones will require intervention

For example, one of the things that we have on our side, are custom pythonizations implemented via a static __cppyy_pythonize__, e.g.: here. cppjit would use __cppjit_pythonize__ with the same effect (at least as far as we can tell), but it’s unclear to me what the plan for this kind of functionality is. Can / should we stay with __cppyy_pythonize__, or should we rather future-proof ourselves and also provide a __cppjit_pythonize__?

---

Some links to issues / PRs, etc. related to that migration that we have found in our (Key4hep) CI:

• Cannot pass enum with fixed underlying type from std namespace as function argument in python any longer · Issue #23615 · root-project/root · GitHub (with a temporary fix: Do not use std namespace for underlying type by tmadlener · Pull Request #532 · key4hep/EDM4hep · GitHub)
• [Python] Use isinstance instead of repr check in RooFit.bindFunction by jmcarcell · Pull Request #23614 · root-project/root · GitHub and Do not rely on the module name to detect cppyy objects in Frame.put by jmcarcell · Pull Request #1031 · AIDASoft/podio · GitHub

[bellenot]

I’m sure @ajomy can give you some details

[jonas]

Dear @tmadlener,

thank you very much for following these developments!

The goal is that the transition is as transparent as possible. That means we’ll put backwards compatibility mechanisms in place where we can. There are limits of course, and [Python] Use isinstance instead of repr check in RooFit.bindFunction by jmcarcell · Pull Request #23614 · root-project/root · GitHub is a good example for that: a typename is just a string that can’t have any backwards compatibility fallback. So using the ROOT._cppyy.types.Function API is the right call there.

In the case of documented magic function names like __cppyy_pythonize__ we can and should put a backwards compatibility mechanism in place. Can you maybe open an issue about this, and similar cases you encounter? The API surface is very large, and there was no way for us to know in advance which part is actually used in practice, so we really appreciate and rely on your input there.

Concerning timeline: ROOT 6.42 will be branched from master in the end of October in and released one month after, with at least one release candidate in between. That gives us the time to sort out these backwards incompatible changes, addressing some with fallbacks and document the final changes in the release notes.

I hope that clears things up!

Cheers,
Jonas

[tmadlener]

Hi Jonas,

Thanks a lot for the quick reply and the information. This all sounds very reasonable to me. Just to make sure: I wasn’t really complaining about the migration and that it breaks things, I was mainly wondering whether the expectation would be more towards “ROOT tries to make this as transparent as possible” or rather “Users will have to fix some of their things”.

Since, at least IIUC, this migration involves quite a few moving parts, should we just open issues against ROOT and you will take care that it get’s to the correct place eventually?

Cheers,
Thomas

[jonas]

@tmadlener

Since, at least IIUC, this migration involves quite a few moving parts, should we just open issues against ROOT and you will take care that it get’s to the correct place eventually?

Yes that’s the best way forward!

Thanks