Environment Modules
DebPkg:environment-modules is a tool to modify your shell environment in a comfortable and modular way.
For most shells the
module command is available by default, otherwise (e.g. on ZSH) source the module profile.
Using existing module files
» source /etc/profile.d/modules.sh
The usage of the
module command is exemplified with the
it.gsi.de repository.
Load the Environment Modules configuration directory with the use sub-command.
» module use /cvmfs/it.gsi.de/modulefiles/
» tree /cvmfs/it.gsi.de/modulefiles/
[…]
|-- compiler
| |-- gcc
| | |-- 3.4.6
| | |-- 4.6.2
| | |-- 4.7.3
| | |-- 4.7.pre
| | `-- 4.8
[…]
The configuration is loaded from a directory called
modulefiles/
containing a single file for each available software component:
When loading a particular software package,
module will ensure to enable dependency software also. Furthermore it will remove eventually conflicting software packages.
List all available software packages with the avail sub-command:
» module avail
----------------------- /cvmfs/it.gsi.de/modulefiles/ -------------------------
boost/1.54 compiler/gcc/4.7.pre compiler/llvm/3.4 openmpi/intel/1.6
cern/2006 compiler/gcc/4.8 compiler/pgi/12.1 openmpi/pgi/1.6.4
compiler/gcc/3.4.6 compiler/intel/12.1 geneva/1.0.1 root/v5.34-14
compiler/gcc/4.6.2 compiler/llvm/3.2 git/1.8.5.5 scalapack/2.0.2
compiler/gcc/4.7.3 compiler/llvm/3.3 minuit2/5.28
[…]
Add software packages to your environment with the load sub-command.
» module load compiler/gcc/4.8
» which gcc
/cvmfs/it.gsi.de/compiler/gcc/4.8/bin/gcc
Undo modifications introduced by a certain module with the unload sub-command.
» module unload compiler/gcc/4.8
» which gcc
/usr/bin/gcc
Creating your own module files
Module files can be created using a text editor of your choice. You can then create, modify or overwrite existing environment variables. You can also define variables local to the module file, e.g. if you need to reuse a version number quite often you could set up a variable with the version, so you only need to replace a single line if you want to create a module file for a different version.
This is an example from the
it.gsi.de
CVMFS repository:
#%Module1.0
# The line above is very important since this is your way of telling environment modules that it should treat this file as a module file
# Here is some tcl code that is called once a user issues "module help THISMODULENAME"
proc ModulesHelp { } {
puts stderr "git/1.8.5.5 - Adds Git 1.8.5.5 from /cvmfs/it.gsi.de to the environment."
}
# Here we define what is returned if user issues "module whatis THISMODULENAME"
module-whatis "Git `.8.5.5 from /cvmfs/it.gsi.de"
# Now we set up a few module file local variables. These will be reused later
set GIT_PATH /cvmfs/it.gsi.de/git
set GIT_VERSION 1.8.5.5
# And we modify two environment variables if this module is loaded:
# First, we prepend a value to PATH.
# The value is we prepend is generated from the 2 variables we declared above.
prepend-path PATH $GIT_PATH/$GIT_VERSION/bin
# Now PATH will start with /cvmfs/it.gsi.de/git/1.8.5.5/bin, followed by the other values that were originally in $PATH.
# This way if you load this module and run a command, the first location your shell will look for a suitable executable will be /cvmfs/it.gsi.de/git/1.8.5.5/bin
# To make sure the git binary will use the appropriate libraries and not those that might ship with a different version of git on the system we also modify the LD_LIBRARY_PATH.
# Again the value that's prepended consists of some characters and the variables we defined above.
prepend-path LD_LIBRARY_PATH $GIT_PATH/$GIT_VERSION/lib
The nice thing about
environment-modules
is that it takes care of reverting the environment when a module is unloaded. You don't need to save the old
PATH
somewhere when creating a module file and then restore it later on. This is done automatically.
For more information about what you can do with module files check
man modulefile
.
Links
--
BastianNeuburger - 03 Sep 2014