When you run root, it’s a symlink to snapd itself, and really runs e.g., snap run root at the Bash level, or is passing the name of the executable you intended to snapd at the main loop, argc level.
Snapd and various helper scripts then collaborate to set up the environment. Some of that will be e.g., mount namespaces where /usr/include/ will be rewritten to have the snaps idea of the stdlib, others will be $LD_LIBRARY_PATH, $PATH, and etc, to include the ROOT utilities and general libraries. All this is done before the ROOT executables themselves are called, and in a manner where the intention is people never have to realise it’s happening in the ideal case.
There is technically .thisRoot.sh in the package, but it’s not modified and isn’t intended to be used, because the ABI of the snap will change overtime (I.E., it’s been GCC 9 / Ubuntu 20.04, GCC 11 / Ubuntu 22.04, and now GCC 13 Ubuntu 24.04) - similarly Python has jumped from Ubuntu’s 3.8 in 20.04 to 3.12 in 24.04) - this means it doesn’t really make sense to mention because by having a use case for it, you’re probably better off avoiding the snap entirely. (Despite this, I do see people do it anyway, and usually it works fine for a period until everything breaks eventually)
It doesn’t make sense to mix the snaps environment with the host environment, so the only thing that’s influenced in the host directly is adding the root symlinks to $PATH, and specifically at a preference lower than most other installations (e.g., if you run ./thisRoot.sh from the upstream binary distributions, then the official CERN ROOT will be preferred entirely, if you were on Fedora with the ROOT snap and then installed ROOT via dnf, whilst the snap is still installed, it’ll be entirely secondary to the main system root)
That probably answers the environment setup, but I’m curious if you had anything else in mind when asking this, because generally my opinion of the snap (as the guy publishing it) is that is has a huge value to certain target audiences and gets highly used. On the other hand, it does cause confusion with more advanced usecases because e.g., it’s impossible to mix Ubuntu system packages with the snap packages (say for e.g., QT or etc) due to the ABI concerns and sandboxing on top.
There’s edgecases in edgecases, so for example, one of the users once got in touch regarding his students who would use ROOT with makefiles, which the snap wasn’t really suitable for. However this then resulted in adding root-framework.gcc, root-framework.make, root-framework.cmake, and root-framework.run as exposed binaries in the host $PATH, so the user could with first year students have a workflow like:
root-framework.make .
root-framework.run a.out
and since that gets built entirely in the container, you get a reproducible environment (if awkward one) that works well in that context. Whilst usable there, it could easily be I’d recommend you another package if your usecase might not quite be appropriate (I don’t take it personally, it does it’s job well, there’s other jobs it does less well, and always other packages to accommodate that).