Spack-stack meta modules in core locations

[DavidHuber-NOAA]

I wonder if it would be possible to convince RDHPCS, et al., to allow spack-stack meta modules to be added to the core suite of modules. For instance, many machines have a contrib suite of module files. Would it be unreasonable to have meta modules copied into the contrib trees so we could do something like the following rather than a module use /a/long/path/to/spack-stack-x.y.z/env/ue-oneapi/install/modulefiles/Core?

module load contrib
module load spack-stack/x.y.z-oneapi  # or spack-stack/x.y.z-gsi-addon-oneapi, etc, for chained environments

One-off installations for testing could continue using the module use /....... This would just be for primary installations.

[rickgrubin-noaa]

I wonder if it would be possible to convince RDHPCS, et al., to allow spack-stack meta modules to be added to the core suite of modules. For instance, many machines have a contrib suite of module files. Would it be unreasonable to have meta modules copied into the contrib trees so we could do something like the following rather than a module use /a/long/path/to/spack-stack-x.y.z/env/ue-oneapi/install/modulefiles/Core?

module load contrib
module load spack-stack/x.y.z-oneapi  # or spack-stack/x.y.z-gsi-addon-oneapi, etc, for chained environments

One-off installations for testing could continue using the module use /....... This would just be for primary installations.

In place of module use /a/long/path/to/spack-stack-x.y.z/env/ue-oneapi/install/modulefiles/Core perhaps on RDHPCS hosts we could create a modulefile (called contrib) outside of the RDHPCS-provided module hierarchy that would encapsulate host-appropriate module use commands, e.g. something like:

module show contrib
[...]
prepend_path("MODULEPATH",  "/a/long/path/to/spack-stack-x.y.z/env/ue-oneapi/install/modulefiles/Core")
[...]

that would add necessary pathing to MODULEPATH, and then a user could issue module load spack-stack/x.y.z-oneapi and similar commands.

We could also investigate using the LMOD pushenv command, which sets an env var to a specified value, and preserves the previous value of that env var in an internal stack before setting the new one, which ensures proper environment restoration when modules are unloaded, e.g.

pushenv("MODULEPATH", "/a/long/path/to/spack-stack-x.y.z/env/ue-oneapi/install/modulefiles/Core")

pushenv() is handy, but we'd also have to be careful to include other paths, particularly those that point to system-provided modules (e.g. git-lfs) so that a user would still be able to load such modules:

pushenv("MODULEPATH", "/important/system/modulepath-1:/important/system/modulepath-2:/a/long/path/to/spack-stack-x.y.z/env/ue-oneapi/install/modulefiles/Core")