This article contains instructions or advice. (February 2015) |
The Environment Modules system is a software tool designed to help users dynamically modify their shell environment. It provides a mechanism for managing and switching between sets of environment variable settings, often used to configure different software packages, compilers, and libraries.
| Environment Modules | |
|---|---|
 | |
| Stable release | 5.6.0
/ July 31, 2025 |
| Repository | |
| Written in | Tcl |
| Operating system | Unix-like |
| License | GNU General Public License#Version 2 |
| Website | modules |
Overview
editEnvironment Modules allows users to dynamically configure their shell environment without permanently altering login scripts. This is especially useful in high-performance computing (HPC) environments where users may need to access multiple versions of the same application. Users load and unload scripts called modulefiles to modify environment variables such as PATH or LD_LIBRARY_PATH.
Environment Modules is shell independent and supports all major Unix shells (Bash, ksh, zsh, Fish, sh, tcsh, and csh), Windows shells (CMD.EXE and PowerShell) and several Scripting languages (Perl, Python, Ruby, Tcl, CMake and R)
Environment Modules handles all kind of items part of shell environment, including environment variable, shell alias, shell function and command-line completion.
History
editEnvironment Modules was first developed in the early 1990s[1] by John L. Furlani at Sun Microsystems. Version 1 was developed as pure shell scripts. With version 2 Environment Modules became a C program evaluating modulefiles written in Tcl.
In the mid 1990s Peter W. Osel at Siemens and Jens Hamisch at Strawberry released the 3.0beta version[2]. R.K. Owen at the National Energy Research Scientific Computing Center (NERSC) took over the project in the late 1990s and ported it to Linux. He released version 3.1 in 2000 under the GNU General Public License (GPL)[3].
During the 2000s, Environment Modules gained traction in the high-performance computing (HPC) world and started to be used at the largest computing centers[4][5]. Environment Modules was specified as a Baseline Configuration requirement of the DoD High Performance Computing Modernization Program (HPCMP)[6].
In 2004, Mark Lakata of MIPS Technologies developed a pure Tcl reimplementation of Environment Modules[7]. Maintenance of this alternative version was later continued by Kent Mein at the University of Minnesota.
In 2008, Robert McLay of the Texas Advanced Computing Center (TACC) introduced Lmod[8], an alternative implementation project of Environment Modules written in Lua.
After the release of version 3.2.10 in December 2012, development of the C implementation of Environment Modules was discontinued. In the following years, the Lmod project grew in popularity within the HPC community.
In 2017, stewardship of the Environment Modules project was transferred to Xavier Delaruelle of the French Alternative Energies and Atomic Energy Commission (CEA). He released version 4, based on the pure Tcl implementation, which was adapted to maintain compatibility with the earlier C version[9]. Since then, new features have been introduced regularly to enhance usability and extend functionality[10].
Modulefiles
editThe modules system is based on modulefiles,[11] which specify groups of environment settings that need to be made together. Modulefiles can be installed in a central ___location for general use, or in a user directory for personal use. Environment Modules modulefiles are written in the Tcl (Tool Command Language) and are interpreted by the modulecmd program via the module[12] user interface.
Modulefiles are created on per application per version basis. They can be dynamically loaded, unloaded, or switched. Along with the capability of using multiple versions of the same software it also can be used to implement site policies regarding the access and use of applications.
Default modulefiles directory
editThe default modules search path is in a hidden configuration file you can display with:
$ cat ${MODULESHOME}/init/.modulespath
/etc/modulefiles # CentOS, Scientific Linux, RHEL
/usr/local/Modules/modulefiles # Build from source default
The /etc/modulefiles directory used by some distributions (or any other directory) can be used after a build from source by modifying the ${MODULESHOME}/init/.modulespath file.
Add your own modules to the path
editThe ${MODULESHOME}/modulefiles/use.own module essentially performs these steps:
mkdir $HOME/privatemodules
cp ${MODULESHOME}/modulefiles/null $HOME/privatemodules
module use --append $HOME/privatemodules
Use a version file within a hierarchical organization
editThe commands in this section require read/write/execute access to the /etc/modulefiles directory. The $HOME/privatemodules or another directory can be used instead along with "module use --append" or modification of the configuration file specifying the default modules search path.
The default modulefiles directory is empty initially. Copy the null module to the default modulefiles directory to have it shown by "module avail". The following uses the null and module-info modules to show use of a version file within a hierarchical organization and their effect on module avail and module show:
mkdir /etc/modulefiles/test
cp ${MODULESHOME}/modulefiles/null /etc/modulefiles/test/2.0
cp ${MODULESHOME}/modulefiles/module-info /etc/modulefiles/test/1.0
module avail
module show test
Set the first version as the default:
echo '#%Module' > /etc/modulefiles/test/.version
echo 'set ModulesVersion "1.0"' >> /etc/modulefiles/test/.version
module avail
module show test
module show test/2.0
Switch to the newer version as the default with:
rm /etc/modulefiles/test/.version
echo '#%Module' > /etc/modulefiles/test/.version
echo 'set ModulesVersion "2.0"' >> /etc/modulefiles/test/.version
module avail
module show test
After the above following a fresh install from source you would see:
$ module avail
-------------------- /usr/local/Modules/3.2.10/modulefiles ---------------------
dot module-git module-info modules null use.own
------------------------------- /etc/modulefiles -------------------------------
null test/1.0 test/2.0(default)
--------------------------- /home/user/privatemodules --------------------------
null
$ module show test
-------------------------------------------------------------------
/etc/modulefiles/test/2.0:
module-whatis does absolutely nothing
-------------------------------------------------------------------
$ module show test/1.0
-------------------------------------------------------------------
/etc/modulefiles/test/1.0:
module-whatis returns all various module-info values
+++ module-info +++++++++++++++++++++++++++++++
flags = 2
mode = display
name = test/1.0
specified = test/1.0
shell = bash
shelltype = sh
version = test/1.0
user = advanced
trace = 0
tracepat = -.*
symbols = *undef*
+++ info ++++++++++++++++++++++++++++++++++++++
hostname = localhost
level = 1
loaded null = 0
library = /usr/local/lib/tcl8.6
nameofexecutable =
sharedlibextension = .so
tclversion = 8.6
patchlevel = 8.6.1
+++++++++++++++++++++++++++++++++++++++++++++++
-------------------------------------------------------------------
Automatic modules initialization
editEnvironment Modules on Scientific Linux, CentOS, and Red Hat Enterprise Linux distributions in the environment-modules package include modules.csh and modules.sh scripts for the /etc/profile.d directory that make modules initialization part of the default shell initialization. One of the advantages of Environment Modules is a single modulefile that supports bash, ksh, zsh, sh as well as tcsh and csh shell users for environment setup and initialization. This makes managing complex environments a bit less complicated.
For a source build the automation for all users can be manually configured.
bash, ksh, zsh, sh automatic modules initialization
edit/etc/profile.d/modules.sh from the etc/global/profile.modules file in the 3.2.10 modules build directory.
trap "" 1 2 3
case "$0" in
-bash|bash|*/bash) . /usr/local/Modules/default/init/bash ;;
-ksh|ksh|*/ksh) . /usr/local/Modules/default/init/ksh ;;
-zsh|zsh|*/zsh) . /usr/local/Modules/default/init/zsh ;;
*) . /usr/local/Modules/default/init/sh ;; # default
esac
trap 1 2 3
Copy the etc/global/profile.modules file from the 3.2.10 modules build directory to the system initialization directory:
$ sudo cp etc/global/profile.modules /etc/profile.d/modules.sh
Add a version 3.2.10 symbolic link for the above generic addresses:
$ cd /usr/local/Modules
$ sudo ln -sT 3.2.10 default
tcsh, csh automatic modules initialization
editA /etc/profile.d/modules.csh symbolic link to the etc/global/profile.modules file in the 3.2.10 modules build directory can enable automatic modules initialization for these users.
Installing on Linux
edityum and rpm
editOn Scientific Linux, CentOS, and RHEL distributions Environment Modules is in the environment-modules package which can be installed with:
sudo yum install environment-modules
Once installed the package information can be viewed with:
rpm -qi environment-modules
rpm -ql environment-modules
apt and dpkg
editOn Ubuntu or systems using apt-get, Environment Modules can be installed with:
sudo apt-get install environment-modules
Once installed the package information can be viewed with:
dpkg -L environment-modules
Linux from source
editAlthough installing from a Linux distributions repository using that distributions update manager is the easiest the software can be installed from source. Resolve dependencies is the most difficult task for an installation from source. The typical configure, make, install cycle can become painfully slow as each configure improvement reveals another dependency not available in your default environment. This section includes the steps to install the Environment Modules package on source including compiling the Tcl from source as a dependency.[13]
8.6.1 version of Tcl built from /usr/local/src
editAlthough the PCLinuxOS 64-bit repositories include Tcl they do not include a development package with the configuration files required to build Environment Modules on Linux from source. Building Tcl from source will make the required files available.[14]
Extract source after downloading
cd /usr/local/src
tar -xvzf ~/Downloads/tcl8.6.1-src.tar.gz
Configure, make, install
cd /usr/local/src/tcl8.6.1
unix/configure
make
sudo make install
3.2.10 version of modules built from /usr/local/src
editExtract source after downloading
cd /usr/local/src
tar -xvzf ~/Downloads/modules-3.2.10.tar.gz
Configure, make, install
cd /usr/local/src/modules-3.2.10
CPPFLAGS="-DUSE_INTERP_ERRORLINE" ./configure
make
sudo make install
References
edit- ^ Furlani, John L. (September 30 – October 3, 1991). "Modules: Providing a Flexible User Environment" (PDF). Proceedings of the Fifth Large Installation Systems Administration Conference (LISA V). San Diego, CA: 141–152. Retrieved 9 February 2014.
- ^ "Module 3.0 Beta 1 is out". SourceForge. 4 October 1996.
- ^ "Modules 3.1.0 almost ready". SourceForge. 28 June 2000.
- ^ "NICS User Support Kraken Modules Description". The National Institute for Computational Sciences (NICS). Oak Ridge National Laboratory - Department of Energy. 22 May 2011. Archived from the original on 22 February 2014. Retrieved 9 February 2014.
- ^ "NERSC Modules Software Environment". The National Energy Research Scientific Computing Center (NERSC). Office of Science - Department of Energy. 2014-02-07. Retrieved 19 February 2014.
- ^ "Use of Modules for Accessing Multiple Versions of Software". Baseline Configuration. DoD High Performance Computing Modernization Program (HPCMP). 20 Mar 2008. Archived from the original on 22 February 2014. Retrieved 9 February 2014.
- ^ "pure TCL implementation of module". SourceForge. 29 October 2002.
- ^ "Announcing Lmod: A new module system". SourceForge. 16 October 2008.
- ^ "Modules 4.0.0 released". SourceForge. 16 October 2017.
- ^ "New features". Read the Docs. 31 July 2025.
- ^ "modulefile". Read the Docs. 31 July 2025.
- ^ "module". Read the Docs. 31 July 2025.
- ^ http://nickgeoghegan.net/linux/installing-environment-modules
- ^ "TCL - Browse /TCL at SourceForge.net".
External links
edit
- Official website
- modules on GitHub
- John L. Furlani, Modules: Providing a Flexible User Environment Proceedings of the Fifth Large Installation Systems Administration Conference (LISA V), pp. 141–152, San Diego, CA, September 30 - October 3, 1991.
- http://www.lysator.liu.se/cmod/ - alternative implementation using C only
- PennState Environment Modules User Guide
- Drag your design environment kicking and screaming into the '90s with Modules! - SNUB Boston 2001 - Erich Whitney, Axiowave Networks, Mark Sprague, ATI Research
- Xsede Software Environments. The Extreme Science and Engineering Discovery Environment ― National Science Foundation
- NICS Modules Description ― The National Institute for Computational Sciences at Oak Ridge National Laboratory ― Department of Energy
- Lmod ― Lua-based module system
- Spack ― Package Manager for HPC Software developed at Lawrence Livermore National Laboratory