[Python] Move JupyROOT to be private submodule of ROOT#21150
Open
guitargeek wants to merge 7 commits intoroot-project:masterfrom
Open
[Python] Move JupyROOT to be private submodule of ROOT#21150guitargeek wants to merge 7 commits intoroot-project:masterfrom
ROOT#21150guitargeek wants to merge 7 commits intoroot-project:masterfrom
Conversation
pcanal
reviewed
Feb 4, 2026
| "python", | ||
| "-m", | ||
| "JupyROOT.kernel.rootkernel", | ||
| "ROOT._jupyroot.kernel.rootkernel", |
Member
There was a problem hiding this comment.
I am confused. Since this is part of the testing, it looks like the users might be doing the same thing. If that is correct was is the backward compatibility plan? If that is not correct, what is the indirect way that user take advantage of JupyROOT?
Contributor
Author
There was a problem hiding this comment.
The user should not write his own kernel file: we ship it via etc/notebook/kernels/root/kernel.json.in.
This kernel file in roottest is probably a remnant of the JupyROOT development process and I'll see if I can remove it.
Test Results 22 files 22 suites 3d 15h 49m 34s ⏱️ Results for commit 418784b. ♻️ This comment has been updated with latest results. |
guitargeek
force-pushed
the
lazy_root
branch
2 times, most recently
from
6d10bd2 to
3cb77f9
Compare
This file is not referred to anywhere in the codebase, and it also is not valid Python becayse `get_config` is defined nowhere.
This was probably left over from JupyROOT development. ROOT ships its own `kernel.json` file in `etc/notebook/kernels/root/kernel.json`.
This is not needed, as namespaces like `ROOT` are dynamically looked up by cppyy. Setting attributes of the ROOT module will only cause trouble in JupyROOT, because the `libROOTPythonization` extension is also imported there.
This cppyy import is deferred to `ROOTFacade._finalSetup(). Delaying this step avoids importing the heavy-weight cppyy machinery unless it is actually required (for example, when accessing C++ ROOT symbols), allowing Python-only ROOT submodules to be imported with minimal overhead.
JupyROOT should not be accessed by the user, and not having it as a separate package makes packaging cleaner. In the end, ROOT should only ship the ROOT package.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
JupyROOT should not be accessed by the user, and not having it as a separate package makes packaging cleaner. In the end, ROOT should only ship the ROOT package.
The PR also contains some commits to defer the import of cppyy and the initialization of the C++ runtime to the last possible moment, so we're not (partially) initializing it when importing the
ROOTmodule. This is what makes it possible to have clean Python-onlyROOTsubmodules like_jupyrootwithout the unwanted sideeffects of initializing the C++ runtime on import.