Using snapped pyroot in a virtualenv

[flibidi]

Hi rooters,

It has been a while since I last used ROOT, and I was thrilled to see that a simple snap install root-framework does the job.
I was even more thrilled to discover that pyroot is then easily available by calling pyroot my_code.py.

To do clean Python work, it is a good practice to use virtual environments.

The problem is : calling pyroot from the virtualenv does not use the Python 3.8.0 of the virtualenv, but Python 3.8.10 (that I do not remember installing)
So the question is : How to use pyroot from the snapped version of Root inside a virtualenv ?

Thanks in advance,

Philippe

[Axel]

@James-Carroll might be able to help?

[James-Carroll]

Hi Philippe

I don’t think the context of a Python virtual environment makes sense for the snap, it’s already isolated from the host system and all its bundled Python packages don’t rely on anything provided from the system, or add anything to the host system. It’s effectively got the characteristics of a Python virtual environment by default.

So while generally using virtual environments is good procedure, it’s likely not a worry here.

pyroot will always use Python 3.8.X regardless of the system Python version (until changed in future releases). It’s shipped with the snap itself, so it doesn’t matter whether you even have Python installed to begin with. Every user of the snap will have a consistent environment. The patch release will go up overtime as security updates are released for Python 3.8 but the patch release itself is expected to remain 100% compatible so it isn’t a worry to see that number go up.

If the reason for wanting a virtual environment extends to wanting more than the default bundled Python packages, I can consider adding any suggestions into the default image or alternatively you might find building your own snap relatively easy (although unfortunately individual packages might have their own problems). There’s also a third option where you can make use of the snaps own built in pip to add some extras packages, and this would be isolated from the rest of the system too, so if there’s any extra packages you need feel free to ask.

[flibidi]

Hi James,
Thank you for the reply.

From what I gather, snapped Root will then not be a solution for me. I use virtualenvs extensively, not just one virtualenv to shield my system’s Python from faulty packages, but one per project to handle my the dependencies finely.

I will fall back to building Root from source then. That should work.

[James-Carroll]

If you were otherwise satisfied with the premise of the snap but wished for precise control over the dependencies, you’d probably find building your own pretty easy.

The python environment comes down to this one file, and the build process should be trivial for anyone capable of compiling upstream ROOT.

Again, some individual packages might introduce problems in snaps unique sandboxing model, but you might also happen to find it just works fine.

[flibidi]

Could you provide a quick link to how to build a snap ? I have absolutely no idea on how to do that…

[James-Carroll]

There’s some link in the readme but for the tl;dr version I’ll try write it up myself:

First step is to install the build tools, which is Snapcraft itself and a backend for it to work in, so that the build environment is reproducible. This either comes down to building in a VM or building in a container, and I’d recommend the container, i.e, LXD.

sudo snap install snapcraft --classic
sudo snap install multipass # If you want the VM approach
sudo snap install lxd # If you want the container approach
sudo lxd init --auto # If you picked LXD, this will set it up magically, but may require a reboot

Next, grab the repository

git clone https://github.com/MrCarroll/root-snap/
cd root-snap
git checkout 6-24

The main branch builds the latest master/HEAD. The branches are generally all similar but may have subtle changes in e.g what packages are pinned.

#If using multipass
snapcraft
#If using LXD
snapcraft --use-lxd

The command will build ROOT from scratch in a clean environment, grab all the Python packages, and bundle them up into a single .snap file at the end.

sudo snap install root-framework_local_file.snap --dangerous

The dangerous flag acknowledges your local copy is unsigned. It’s still heavily sandboxed, you could remove a lot of the sandboxing with --devmode which is a cheat mode to completely remove all the AppArmor policies (but keeps its own mount namespace & etc)

sudo snap alias root-framework root
sudo snap alias root-framework.pyroot pyroot
sudo snap alias root-framework.rootbrowse rootbrowse
# Continue for however many you actually care about

These final steps alias the built in package names to their normal names

Since all the Python packages will be in the .snap file, and will never update unless you explicitly rebuild and reinstall it, they’ll be frozen forever and copyable across other machines, along with the entire GCC toolchain and ROOT libraries they depend upon.

(But Python will still increase in 3.8.X, though it’s very very very much ensured to be compatible and would never jump to a new major version, this is because the Python installation is actually in the core20 snap and not the ROOT snap, but you could actually change that too though I’d not personally bother).

[flibidi]

Thank you a lot ! I’ll try it out