Spack Environments - EpiModel/EpiModeling GitHub Wiki

spack offers an environment feature. This is similar to renv for R. Where only a subset of the available modules are available to the environment and the configuration is shareable.

loadR.sh with `spack* environment

Considering a loadR.sh script like so:

#!/bin/bash
. /projects/epimodel/spack/share/spack/setup-env.sh
spack load [email protected]
spack load [email protected]

with an environment called epimodel, the script would be:

#!/bin/bash
. /projects/epimodel/spack/share/spack/setup-env.sh
spack env activate epimodel
spack load r
spack load git

The only difference is the activation of the environment spack env activate epimodel and the removal of the version for the modules loaded. As the environment contains only one version of each package.

Creating an environment

Like git branches or renv environments, spack environments are cheap. They share the same modules as the global spack installation.

To create an epimodel environment, we run:

spack env create epimodel

We activate and deactivate it with:

spack activate epimodel
spack deactivate

Within an environment, spack add [email protected] will add R version 4.3.x to the environment. spack install then resolve the dependencies and install the missing modules. Installed modules are also available outside of the environment but the version (@x.x.x) needs to be specified.

Example

Let's create an epimodel environment with gcc@13, [email protected], [email protected] and a few R packages.

spack env create epimodel
spacke env activate epimodel

# the compiler is added first, in case it needs to be compiled
spack add gcc@13
spack install
spack load gcc
spack compiler find

# then the rest of the packages are installed
spack add [email protected]%gcc@13 [email protected]%gcc%13 r-renv r-tidyverse r-ergm
spack install

From there on, the packages can be loaded without mentioning the version as there will be only one available.

In this example, we did not specify [email protected] or [email protected]. spack will use the latest version matching [email protected] and gcc@13. However, the spack.lock file will contain the exact version installed.

Multiple environments, for different versions of R can be maintained on a single HPC. The user would only choose the right environment to activate for the project and the rest of the commands would be unchanged. Also, the admin could install update to some software without breaking the users projects (going from [email protected] -> [email protected] for example).

Advantages

Environments allow the isolation of packages and simplifies the usage of spack for end users.

Similarly to how renv allows multiple project to use different versions of R libraries, spack environments extend this to non R software. This becomes important where multiples languages are used in a project or when some R packages require older versions of some low level libraries in order to be compiled.

For end users, the self contained nature of environments means that they can activate them and load the packages without the need to find the compilers or know the exact version of each software. This task is only left to the spack admin that will create the environments.

Finally, an environment can be shared via a lock file to further the reproducibility of a project.