I’m fairly new to linux and whatnot, so please be nice. I have had ROOT notebooks running just fine using a snap package install on Ubuntu.
Then I needed to run a python package written by a friend of mine for use in Jupyter notebook. He knew nothing about snap packages, but helped me with the install with pip using a virtual environment (I’m unclear how snaps differ from environments) as documented here: [not allowed].
Now when I try to run ROOT --notebook, I get: " No module named ‘notebook.notebookapp’ ". I can however, still import ROOT from within python when I’m not in the virtual environment. Does anybody have any idea why my notebooks have broken? Thanks.
Could you show the commands you’ve used to setup the virtual environment?
I wouldn’t expect a venv to be able to permamently break the snap; it’s immutable and can’t be easily changed. I imagine what’s going on is there’s an environment variable being passed into the snap from whatever venv commands are being run that causes a conflict with the snaps own Python environment, resulting in a temporary failure that should resolve if those variables weren’t there.
If you want to add pip packages to the snap, you’d do it like
root-framework.pip install packagename
Although the snap doesn’t use virtual environments specifically, for all intents and purposes it’s always in its own virtual environment and wouldn’t pick up on changes that were done by other means.
I’d imagine that rebooting the system and trying the pip install like the example above should sort things out; so long as you haven’t e.g made the virtual environment apply automatically on boot via .bashrc or similar.
As an aside, you might want to pause automatic updates if you install your own pip packages with sudo snap refresh --hold root-framework, so that the underlying version of ROOT doesn’t change potentially breaking the pip packages you’ve installed, since those packages wouldn’t be updated automatically.
Thanks. It prevented me from posting a link, but these are the commands:
$ pip install virtualenv
$ python -m venv emgfit-env
$ source emgfit-env/bin/activate
(emgfit-env) $ pip install --upgrade emgfit
(emgfit-env) $ python -m ipykernel install --user --name emgfit-env
Unfortunately, I think I ran them out of order, accidentally running some things out of the virtual environment that were supposed to be run inside the virtual environment.
I THINK what I want to do is use the virtual environment to run the new package (for a specific task) in a jupyter notebook so I can follow the readme instructions that are not optimized for snap, and independently run the root framework snap as my main ROOT/python install because that had been working reliably before this. But I’m open to suggestion if a different solution would be more reliable.
I think maybe I might not have the correct “source” now to run ROOT.
I tried some things like: sudo source /root/snap/root-framework/current, but I continue to get this error when I try to start a notebook:
Traceback (most recent call last):
File "/snap/root-framework/924/bin/jupyter-notebook", line 5, in <module>
from notebook.notebookapp import main
ModuleNotFoundError: No module named 'notebook.notebookapp'
Hey again,
You really shouldn’t source the snap directly. It’s never guaranteed to be compatible with the host system, by doing so it doesn’t run in the snap container at all. Strictly speaking it could work on a lot of systems (e.g. likely does run fine on Ubuntu 22.04 coincidentally, since that’s where it’s built); but at that point, it’s the same as running a precompiled binary package at best, or just running a broken incompatible build at worst.
What I imagine is going on with the above is that the Python virtual environment unsets/changes $PYTHONPATH so that it doesn’t include the Jupyter environment included with the Snap. The thisRoot.sh script adds back the ROOT specific Python modules, which is why import ROOT continues to work. All of this sounds like it’s running in Ubuntu 22.04, so, it happens to be ABI compatible by chance, but you’d experience major issues if trying the same on e.g. Fedora.
In terms of clean solutions, you effectively have
- Transition from the snap to the pre-compiled binary packages, which integrate with the host system much cleaner since they’re not run in a sandbox.
- Transition to the Conda package with effectively the same results but integrating with the Conda ecosystem.
- Add the Pip package to the snap via
root-framework.pip install emgfit per above.
While I have said there’s a technical downside to doing 3), in that the Pip packages installed by the user aren’t managed with the snaps normal update process and so can technically fall out of sync, in reality, we’re probably talking a maximum of 10 minutes of effort every 2 years to sort that out. It’s not going to be the case that it falls apart every couple of hours, days, or even weeks; especially not if the updates are turned off or major releases pinned.
Ideally, the easiest is probably 3) if you’re already happy with the Snap and it’s just this one Pip package that’s needed. But otherwise, I’d pick 1) or 2). Sourcing from the /snap directory is something that’s essentially guaranteed to break eventually or cause subtle problems elsewhere, and really I should filter thisRoot.sh from the build entirely since there’s never a situation with the Snap where it’s useful/reliable to have.
For what it’s worth, you could have a pre-compiled official release, Conda release, and Snap release, all installed and working side by side without interfering with each other.
Thanks a lot. I’m going to spend some time parsing all this and see what I can figure out!
Thanks a ton, it seems to be working again!
I installed anaconda and followed these instructions:
$ conda config --set channel_priority strict
$ conda create -c conda-forge --name <my-environment> root
$ conda activate <my-environment>
I also did:
pip install jupyter
pip install metakernel
Hopefully that all makes sense. The only difference seems to be that I run a python kernel instead of a ROOT kernel now.
After Jupyter was closed, all the packages stopped working. I needed to reinstall things like numpy and ROOT.
However, conda install -c conda-forge root was unable to solve the environment. It is retrying with a “flexible solve” but it has been going for a really long time now. Am I doing something wrong?
I ended up with this:
Solving environment: unsuccessful initial attempt using frozen solve. Retrying with flexible solve.
Solving environment: |
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
Examining pyarrow: 95%|████████████████████▊ | 479/506 [37:57<00:59, 2.20s// Killed
Hi,
I’ve just uploaded a new version of ROOT for the release that’s just happened. Alongside it, I’ve added a new desktop shortcut for JupyROOT specifically, e.g:
Unfortunately it’s difficult for me to work out what’s was going on in your attempts. Ultimately I think it’s likely just some confusion between the the different versions of Python on the system and how all the variables interact with each other. If you open JupyROOT via the start menu/application overlay, in theory it’ll be immune to temporary changes in any terminal and so should “just work” regardless of other changes going on, since it’ll have the default environment variables for your desktop session unless people modify /etc/environment or something similar.
It should update automatically but you can speed it up with sudo snap refresh to get it sooner.
(N.B, the JupyROOT environment upgraded to Notebook 7 in this release so the UI will look slightly different, but that’s to be expected!)
I don’t remember everything about how I fixed it, but a lot of my difficulties were solved when I had created appropriate environments (using anaconda now), and remembered to switch to the correct environment for the task I was performing using “conda activate ”.
When things entirely stopped working for no good reason, I restarted my computer (aka: “have you tried turning it off and back on again?”).
