Hello world!
For the past month, I’ve had a snap package of of ROOT available at https://snapcraft.io/root-framework. For those unfamiliar with Snap, it is Canonical’s attempt at a container based packaging format for the GNU/Linux ecosystem. Effectively, it holds a similar place as Docker and thus the Dockerised version of ROOT, but fundamentally tries to differ on execution of the user experience.
While there has been adoption so far, there has been a lack of actual feedback on the user experience, so I’ve decided to open a thread here to see if anyone would be willing to give this a go, and give any feedback positive and negative about their experience with it.
Particularly, my hope is that a snap version of ROOT significantly lowers the barrier to entry of acquiring ROOT on Linux in the first place, particularly around newbie ROOT users, such as those who might be starting a physics degree and have comparitively little Linux system knowledge. On Ubuntu in particular, Snap is integrated into the desktop app store by default, and this means you can right now search for ROOT in Ubuntu’s app store and install it, along with PyROOT (which has some special requirements below) and JupyROOT, all in a single click! For other systems, the level of default integration with snap varies, but snap is generally available on a wide variety of distributions, Ubuntu, Debian, Fedora, CentOS, OpenSuse, Arch Linux, Manjaro, etc. And the one single snap build should in theory run on all of them, regardless of their distribution version, system packages, etc. Like Docker, a snap is designed to be entirely self contained.
On Ubuntu, where snap is setup and ready to go out the box, an install of ROOT via CLI would be as simple as the following.
sudo snap install root-framework
root
The snap can access the users normal $HOME directory, can make use of OpenGL acceleration, and on newer versions of snapd, should even work fine with X11 forwarding.
For some extra conveinience, desktop icons would become available in the start menu on most systems too, allowing access to ROOT and a Python 3.8 shell containing PyROOT.
In this package, PyROOT differs rather heavily from installing ROOT with the official distribution, to access PyROOT, run pyroot at the system shell (or use the start menu entry). On the positive side, this guarantees everyone will be running the exact same Python 3.8 prompt, and Matplotlib, Pandas, SciPy and NumPy are included too.
And Jupyter Notebooks are pre-setup too, root --notebook should work absolutely fine!
A quick summary,
key advantages:
- A single build will work on multiple distributions regardless of their system state, so a user will not have to worry about changing versions of GCC, updating the host OS, missing dependencies or ABI incompatibility. No deveopment packages are required to be installed (C++ headers).
- Snaps automatically update, ensuring that everyone is always running the latest patches. The updates are also downloaded as delta patches, so are bandwidth efficient. (I’m aware some people see this as a negative, there are ways to deny the automatic updates but they are intentionally obscure).
- Snaps attempt to set up sandboxing by default. The support varies per distribution, but it does provide some protection against certain threats, or certain coding mistakes.
- Snaps are confined, so you can add and remove the ROOT snap without effecting any other installation of ROOT.
- A modern release of Python for everyone! (3.8).
- Overall, a docker like experience with less setup than docker.
Key disadvantages:
- Snaps cannot generally read/modify system state, so adding new python packages, new libraries, or making other package changes can only be done by rebuilding the snap. (So if there’s any really obvious ones worth bundling by default, please tell me!)
- Snaps automatically update, and some people like the idea of having a single build that never changes. (This can be partially resolved, it’s possible with snaps to make individual releases available, 6.20.x, 6.22.x, etc; if there’s a demand for it it can be done).
- As a result of auto updating and other problems of differing compiler versions / system libraries and general user experience, I can’t recommend trying to compile/link against the libraries in the ROOT snap, so workflows involving building a custom executable to run against ROOTs libraries likely won’t work.
- PyROOT doesn’t act like the normal installs,
import ROOTdoes not work in the system Python shell. - Proof isn’t currently working, it doesn’t fit the general target audience for this snap, but I can look into it if there’s a demand.
- CUDA support doesn’t work, upstream snapd work is required to solve this, proposals exist but are not being actively worked on.
- Currently only distributed for X86_64 CPU’s, but there is the possibility to produce other architecture versions, E.G for Arm64.
As a special note, snaps do not work on Windows Subsystem for Linux 2 by default as Ubuntu in WSL2 uses a custom init system rather than systemd which is a requirement for snapd. As a hack, you can attempt to get snaps to work, and ROOT in particular has good success in my testing. (including running a JupyROOT notebook in a Windows browser, and reading and writing to the Windows desktop, in the snap environment). Despite being technically possible, it’s not a usecase that I can say is supported, but I’d love to be supported properly in the future. https://discourse.ubuntu.com/t/using-snapd-in-wsl2/12113
So thanks for making it this far! Hopefully you might find the ROOT snap interesting, feel free to give it a go and see how it works for you, and if you have any feedback I’d love to hear it! There’s install instructions for a lot of common distributions on the link to the store above.