Component submission: environment-modules

[xdelaruelle]

---

Software Name

Environment Modules

---

Public URL

https://envmodules.io/

---

Technical Overview

Environment Modules project provides an alternative module implementation to Lmod with many new features to smoothly manage user environment and a lot more to come in the future. Modules is now a Linux Foundation project part of HPSF

As of version 5.6, Modules supports:

• Hierarchical module organization
• All Lmod Tcl modulefile commands (copes with the family, depends-on, module try-add commands used in OpenHPC modulefiles.

More information:

• List of major new features with examples: https://modules.readthedocs.io/en/latest/MIGRATING.html
• A detailed comparison with Lmod: https://modules.readthedocs.io/en/latest/other-implementations.html

The aim of this submission is to allow OpenHPC users to use Environment Modules on their OpenHPC installation instead of Lmod if they want to. This is not to replace what is currently set as default but to provide an alternative solution.

This integration will require to have all modulefiles and modulercs of ohpc repository written in Tcl, or at least a Tcl modulefile for each Lua modulefile you would like to keep (Lmod copes very well this that). There are a few exceptions but the ohpc repository already mostly contains Tcl modulefiles.

We will provide all the required support for this integration and on the module topic at large, as we always do with projects integrating ours (RHEL, Spack, EasyBuild).

---

Latest stable version number

5.6.1

---

Open-source license type

GPLv2+

---

Relationship to component?

• contributing developer
• user
• other

If other, please describe:

---

Build system

• autotools-based
• CMake
• other

If other, please describe:
configure script is a bash script, but it acts like an autotools-generated configure script.

A RPM spec file is available at https://github.com/cea-hpc/modules/blob/master/contrib/rpm/environment-modules.spec.in

Does the current build system support staged path installations?
For example: make install DESTIR=/tmp/foo (or equivalent)

• yes
• no

---

Does component run in user space or are administrative credentials required?

• user space
• admin

---

Does component require post-installation configuration.

• yes
• no

If yes, please describe briefly:
If you want to achieve an initial configuration of the user environment, with default modulepaths set and default module loaded, the /etc/environment-modules/initrc configuration file has to be changed. For instance, to reproduce a similar configuration than the one set in /etc/profile.d/lmod.{sh,csh}:

#%Module5.0
# ensure that module command is still defined in sub-shells
module config set_shell_startup 1

module use /opt/ohpc/pub/modulefiles
if {[module-info username root]} {
    module use /opt/ohpc/admin/modulefiles
}

# Load baseline OpenHPC environment
module try-add ohpc

---

If component is selected, are you willing and able to collaborate with OpenHPC maintainers during the integration process?

• yes
• no

---

Does the component include test collateral (e.g. regression/verification tests) in the publicly shipped source?

• yes
• no

If yes, please briefly describe the intent and location of the tests.
Modules is shipped with:

• a testsuite, checking that the generated modulecmd.tcl script behaves properly for all a large variety of situations (24k+ tests): run make test
• an installation testsuite, checking the overall Modules installation behaves properly (1k tests): run make testinstall

All these tests rely on the DejaGnu framework

---

Does the component have additional software dependencies (beyond compilers/MPI) that are not part of standard Linux distributions?

• yes
• no

If yes, please list the dependencies and associated licenses.

---

Does the component include online or installable documentation?

• yes
• no

If available online, please provide URL.
https://modules.readthedocs.io/en/stable/INSTALL.html

---

[Optional]: Would you like to receive additional review feedback by email?

• yes
• no

[xdelaruelle]

We will of course provide a pull-request for this. But we need to first check with OHPC project that such pull-request has a chance to be accepted, given the fact that we did not receive any feedback on our original submission of 2022.

[adrianreber]

@xdelaruelle Thanks for submitting it here. I will present this at the next TSC meeting.

[adrianreber]

Hi @xdelaruelle,

Thanks for submitting this and for your patience since the original 2022 submission. We discussed this at the TSC meeting and the OpenHPC project is open to including Environment Modules as an alternative to Lmod.

That said, there are a few things we'd need to work through together, and we'll need your active involvement throughout the integration process:

Module file format (TCL): The good news is that the vast majority of our module files are already written in TCL format. However, there are currently 5 component spec files (gnu-compilers, boost, tau, metis, plasma) that generate
Lua-format module files. For Environment Modules to work as an alternative, we would need TCL-format module files for all components. Since Lmod handles both TCL and Lua transparently, providing TCL versions alongside (or instead of)
the existing Lua ones should be feasible, but this needs to be verified and implemented. We'd appreciate your help with identifying what exactly needs to change and providing the corresponding patches.

Documentation: The OpenHPC installation guide would need to be updated to document how to install and configure Environment Modules as an alternative module system. This includes the initial configuration you described (e.g., the initrc
setup). We'd need you to help write or review those documentation sections.

Test suite: OpenHPC has a CI-driven test suite that validates component installations. We'd need test coverage to ensure that the Environment Modules integration works correctly — both for the module system itself and to confirm that
existing component modules load and function properly under Environment Modules. Your help in writing and validating these tests would be essential.

We're happy to guide you through the OpenHPC build system, documentation structure, and test framework, but we do need you to drive the implementation since you have the domain expertise on Environment Modules. Without your active
participation in preparing and testing the patches, documentation, and test cases, it's not something we'd be able to take on ourselves.

If you're still willing and able to collaborate on all of the above, we'd welcome a pull request and can help you get started with the specifics of our build and test infrastructure.

[xdelaruelle]

Many thanks for this positive return @adrianreber and also thanks for your guidance.

I am totally ok to do the work described.

In terms of planning, we will release our next version somewhere during Q3 and I currently plan to work on this OpenHPC integration after the release of this next version.