Typically users initialize their shell environment when they log in a system by setting environment information for every application they will reference during the session. The Modules project, also referred as Environment Modules, provides a shell command named module that simplifies shell initialization and lets users easily modify their environment during the session with configuration files called modulefiles.
The Modules project has a long history as its development was started in 1991. At that time, the concept of the module command was laid down to dynamically and atomically enable environment configurations during a shell session. Since then, this concept has become a standard practice, especially among the scientific community where people share same computing resources but all have a specific software and version requirement.
After an almost 5-year release hiatus, Modules with its version 4 is back into the environment management game. The intend is to further improve the modulefile standard and the module command capabilities, with proven concepts applied to similar fields like software package management.
After briefly explaining the root concept behind the module command, this talk will cover the major changes between versions 3.2 and 4 at both software and project level. Then focus will be put on some of the recent or upcoming new features:
* virtual modulefiles
* extend the module command at your site
* sharing code across different modulefiles
* dependencies management between modulefiles
* new ways to query or change the environment state
The audience for this talk is anyone who is interested in user environment management. From the system administrator, who has to provide access to a software catalog, to the end-user of shared computing system, who need to juggle with different workloads combining software elements.
