Load the dependencies of a module without loading the module itself #715

When a modulefile declares requirements through prereq, depends-on or always-load, loading this module automatically loads those dependencies first. There is no way to ask for the dependencies only: the module itself always ends up loaded along with them.

Feedback gathered at the HPSF Conference 2026 highlighted a common situation where this is a problem: rebuilding or developing a piece of software for which a module already exists. The developer wants the exact environment the module relies on (compiler, MPI library, numerical libraries, ...) to be loaded, so the build picks the right toolchain, but does not want the module of the software itself to be loaded, as it would put the installed version in the PATH, LD_LIBRARY_PATH or CMAKE_PREFIX_PATH ahead of the one being built and lead to confusing results. Today, people either load the module then unload it, which is not reliable as the unload may also drop the automatically loaded dependencies, or they read the modulefile and load its requirements by hand, which is tedious and drifts as the modulefile evolves.

Other tools expose this concept directly: Spack provides spack load --only dependencies and spack build-env to set up the build environment of a package without the package itself. Sites that generate their modulefiles from Spack or that have users coming from Spack expect a similar ability from module.

The need is for a way to load all the dependencies of a given module, as they would be resolved and loaded if the module itself were loaded, while leaving that module unloaded. The dependencies should be loaded following the same rules as a regular load (same ordering, same automatic resolution of transitive requirements, same handling of variants and conflicts), so the resulting environment is identical to the one the module would run in, minus the module itself. It should be possible to combine this with the usual load options and module specification syntax, including variants.

This would make module a natural tool to set up a build or development environment from an existing module and would avoid error-prone manual reproduction of dependency lists.