root_base based build doesn't have root in PATH

[matthewfeickert]

In pyhf/pyhf-validation PR 9 is was discovered that the current build doesn't have root or hist2workspace in PATH even though Python knows about PyROOT. This is curious and seems to be a direct effect of that fact that a root_base build is used, as if root_base

pyhf-validation-root-base/Dockerfile

Lines 14 to 15 in d7e3ad6

	RUN conda create --yes --quiet -p /opt/condaenv \
	"root_base=$ROOT_VERSION" \

is replaced with root then everything proceeds as normal with root or hist2workspace in PATH.

It seems that something basic is being missed, and that @henryiii and @chrisburr might be able to give some guidance here.

[matthewfeickert]

@kratsg has pointed out that root_base doesn't doesn't copy any of the compiled C++ code over, a build that is based on root_base won't actually have a working ROOT installation (though PyROOT will work). The build should use the conda-forge package root-binaries instead to get a ROOT runtime.

[chrisburr]

I would suggest using:

   "root_base=$ROOT_VERSION" \
   "root-binaries" \

For a little more context, root is split in to four packages on conda-forge:

• root-dependencies: A meta-package of ROOT's full dependencies (except compilers)
• root_base: Everything that is build with ROOT except the bin/ folder.
• root-binaries: The contents bin/ (this means root_numpy can install fewer packages without giving people broken root binaries on PATH)
• root: A meta-package that depends on all of the others, as well as compilers. This is the only package that I recommend and actively keep stable.

If you see any crashes from missing dependencies that aren't obvious, ping me and I can probably guess what you're missing.

Our curiosity, how does this change the compressed image size? If it's still notably larger I can try and look in to why if you can push both images somewhere (CERN GitLab's container registry?).

[matthewfeickert]

Thanks very much for being so willing to help, @chrisburr. I really appreciate this information. However, we were able to get a ROOT source build working in PR #7, which gets us down to a current compressed image size of 352.03 MB.

Our curiosity, how does this change the compressed image size? If it's still notably larger I can try and look in to why if you can push both images somewhere (CERN GitLab's container registry?).

When using the root-binaries package based build the size was just around 550 MB, and the root package based build was around 560 MB.