NixOS
python3Packages.root: add Python package for root
Closes #241454.
I checked that this works with different Python versions, from Python 3.10 to Python 3.13.
@ShamrockLee, @veprbl
Some comments after going through the code:
- How about converting the dependent Python packages to use
python3Packages.root? - Adding package tests for C++ source/so loading would also be great.
Hi @ShamrockLee, thanks for your messages and get well soon!
How about converting the dependent Python packages to use python3Packages.root?
You have maybe a more concrete suggestion? I didn't find any Python packages, i.e. packages created with buildPythonPackage or buildPythonApplication, that depend on ROOT. What I find were hybrid C++/Python packages like ROOT itself, for example hepmc3. But given their hybrid nature, I didn't see any meaningful way to use this new ROOT Python package there. Or in other words: I didn't find any package that uses the ROOT Python bindings but also uses standard Python package management via pkgs.python3.withPackages, which is what this PR supports.
Adding package tests for C++ source/so loading would also be great.
This is already part of this PR, as explained in the inline comments. Part of the checks is to include ROOT submodules like ROOT.Experimental or ROOT.Math, which are dynamically created submodules only if a corresponding namespace exists in C++. And one can only get a handle on C++ namespaces with PyROOT if the C++ headers (or precompiled modules) and libraries are loaded correctly. If that would not be the case, importing namespaces like ROOT.Experimental would fail with a "module not found error".
I didn't find any Python packages, i.e. packages created with buildPythonPackage or buildPythonApplication, that depend on ROOT. What I find were hybrid C++/Python packages like ROOT itself, for example hepmc3. But given their hybrid nature, I didn't see any meaningful way to use this new ROOT Python package there. Or in other words: I didn't find any package that uses the ROOT Python bindings but also uses standard Python package management via pkgs.python3.withPackages, which is what this PR supports.
Thank you for the investigation! I had thought that hepmc3 were a typical Python package when commenting.
This is already part of this PR, as explained in the inline comments. Part of the checks is to include ROOT submodules like ROOT.Experimental or ROOT.Math, which are dynamically created submodules only if a corresponding namespace exists in C++. And one can only get a handle on C++ namespaces with PyROOT if the C++ headers (or precompiled modules) and libraries are loaded correctly. If that would not be the case, importing namespaces like ROOT.Experimental would fail with a "module not found error".
Did they cover the interface that loads the user-defind C++ program, such as gSystem.Load() and gInterpreter.ProcessLine?
Did they cover the interface that loads the user-defind C++ program, such as gSystem.Load() and gInterpreter.ProcessLine?
No, the import checks only make sure that C++ namespaces from ROOT can be seen (which should imply that other things like classes work too).
But it's a good idea to also check that the interpreter works with C++ user code! I have added checks for gInterpreter.Load() and gInterpreter.Declare().
This looks fine to me. Symlinking whole "${root}/lib" feels a bit hacky, but I don't see any obvious practical issue with doing that.
Thanks for the review! The solution will be cleaner in ROOT 6.38, where I'll make sure that the CMAKE_INSTALL_PYTHONDIR can be separate from the CMAKE_INSTALL_LIBDIR. Right now, it's not possible because of the hardcoded rpaths that the ROOT build system sets. See also:
- https://github.com/root-project/root/pull/18969
@veprbl, can this be merged? I think we converged to a good state, thanks to the review comments!