Our Rocky 8 environment has the latest environment-modules package installed. Some users are looking to get to version 4.6 because that seems to provide the capability to source modules. They would like to use this for automation of their shared resources in our HPC environment. Is there a path to deploying version 4.6 at any time?
Since Rocky is based on RHEL, then I would say if RHEL releases that then yes it would appear in Rocky 8. Otherwise, then no. At least unless someone unoficially provides it, for example in EPEL or somewhere.
You could use Rocky 9 that has the 5.3.0 version.
EPEL has Lmod version 8.7.55-1 for both el8 and el9.
The Lmod is Lua-based alternative. It prefers Lua-syntax modulefiles, but can also use Tcl-syntax (it translates on the fly). The only twist is that if one installs environment-modules after Lmod, then /etc/alternatives points to wrong ‘module’ command. (The Lmod does also have comfy ‘ml’ wrapper to ‘module’.)
I have not seen a need to source in HPC. In fact, many modulefiles are translated from sourced sh that application comes with. (The Lmod has a script for that too.)
Likewise, Python venv’s are usually “activated” by source. I rather write modulefile that sets (and unsets) those variables.
Note: The scl tool of Software Collections used to start process with environment. The current version – at least on el9 – can also call “module load” (and its package requires the environment-modules).
The “module load X” does effectively source a modulefile X. The added convenience is that there does not have to be a file version of every shell that users may use – the tool translates (from Tcl or Lua). Equally importantly, we get the “module unload X”; for typical modulefile we can “undo the source”.
What is that “source module”, actually?
The sourcing is part of an automation process they are developing, not standard for HPC environments, but for what they want to run. And yes, we know that the command “module load X” works, but they’re trying to automate the process of which modules get loaded only for their project. Supporting a number of scientists working on different projects with varied needs means that loading modules, and specific versions of modules, needs to be done on the fly.
The Lmod version supports things like if you have module version X loaded (which has loaded other required modules) and you switch to version Y, all the required modules switch too (if same version is not ok). Furthermore, all modules depending on mpi/x.y can remain hidden from ‘module avail’ unless mpi/x.y is loaded.
Are those the kind of “on the fly” actions that you are looking for?