What a module exports

A reader who only ever module-loads starts here. The recipe that produced the modulefile is on the other pages; this page is the load.

The modulefile is the deliverable. What it prepends and sets is what a user actually receives.

What a module exports is the load: paths, environment, and the modules it still needs.

Questions

• What does a generated modulefile actually export?

• Which variables are always set, and how are they spelled?

• What is the citable name of an installed package?

What you will be able to do

1. Read a generated modulefile and say where each line came from.

2. Name the variables EasyBuild always sets, and find one with module show.

3. Say what a module naming scheme changes, and what a hierarchical one does to MODULEPATH.

The citable unit consists of name, version, toolchain and versionsuffix. Neither the easyconfig filename nor EasyBuild is part of it. FORCE11 software citation requires the specific version that was executed. What “installed” means stated that the modulefile is the only artifact a user encounters, and then did not open one. An example is provided.

A real modulefile

QMCPACK 4.4.0, abridged

$ sed -n '1,34p' \
> .../modulefiles/chem/QMCPACK/4.4.0-foss-2025a.lua
help([==[

Description
===========
QMCPACK is an open-source quantum Monte Carlo simulation code.

More information
================
 - Homepage: https://qmcpack.org
]==])

whatis([==[Description: QMCPACK is an open-source quantum Monte ...]==])
whatis([==[Homepage: https://qmcpack.org]==])
whatis([==[URL: https://qmcpack.org]==])

local root = ".../software/QMCPACK/4.4.0-foss-2025a"

conflict("QMCPACK")

depends_on("foss/2025a")
depends_on("Boost/1.88.0-GCC-14.2.0")
depends_on("HDF5/1.14.6-gompi-2025a")
depends_on("Python/3.13.1-GCCcore-14.2.0")
depends_on("libxml2/2.13.4-GCCcore-14.2.0")

prepend_path("CMAKE_PREFIX_PATH", root)
prepend_path("LD_LIBRARY_PATH", pathJoin(root, "lib"))
prepend_path("LIBRARY_PATH", pathJoin(root, "lib"))
prepend_path("PATH", pathJoin(root, "bin"))

Recorded: SURF Snellius, generated modulefile, 2026-09-10, EasyBuild 5.3.1

Nobody wrote that file. Every line came from somewhere in the easyconfig. Being able to read each export after module load is most of what this page is for. help and whatis come from description and homepage. Those parameters exist. A one-line description is worth writing properly. It is what a user sees from module whatis. conflict("QMCPACK") comes from the name. Two versions of the same software cannot be loaded at once. The module says so rather than letting a user discover it through a strange failure. Smith et al. [2016] require a citation to name the specific version and the platform variant. The module’s full name is that variant: software, version, toolchain, versionsuffix. A paper that writes “GROMACS” has not cited a module. depends_on is the dependencies list from Build dependencies are not dependencies. The list is resolved to specific modules by the robot. It is depends_on and not load. Lmod counts references. Unloading QMCPACK unloads HDF5 only if nothing else still depends on it. The prepend_path lines are the standard set. They were added. No parameter asked for them.

The variables EasyBuild always sets

These entries are not shown in the excerpt above.

Variable	Contents
$EBROOTQMCPACK	the install directory
$EBVERSIONQMCPACK	the version
$EBDEVELQMCPACK	a path to the development-support file

convert_name converts characters to uppercase. convert_name translates - to min. convert_name translates + to plus. convert_name removes periods. code-server is transformed into EBROOTCODEMINSERVER. netcdf-c is transformed into EBROOTNETCDFMINC rather than EBROOTNETCDFC. The min convention follows the easyblock filename pattern. The min convention does more than strip punctuation. Modifying the toolchain changes the module name. Modifying the suffix changes the module name. Modifying the toolchain changes the .eb filename. Modifying the suffix changes the .eb filename.

name = 'QMCPACK'
version = '4.4.0'
toolchain = {'name': 'foss', 'version': '2025a'}
versionsuffix = '-HDF5-1.14.6'

$EBROOT* is used by a recipe. An easyconfig points at a dependency without hardcoding a path, as described in How a build executes’s --with-hdf5=$EBROOTHDF5. The dependency’s module was loaded during prepare. The variable is set. The build never needs to know where the site puts things.

Adding to the module

Four parameters appear in approximate order of frequency of use. modextravars defines additional environment variables. A package that needs FOO_DATA_DIR inside its installation gets it via this parameter. modextrapaths inserts a prefix into a path-like variable. The mechanism lets a Python package add its lib/python3.13/site-packages to $PYTHONPATH. It lets an R package extend $R_LIBS_SITE. modluafooter appends raw Lua code to the modulefile. modtclfooter appends raw Tcl code to the modulefile. It offers an escape hatch for cases not covered by the other parameters. Use it knowing that it binds the easyconfig to a specific module syntax. modaltsoftname changes the filename used to store the module and keeps the software’s original name. It is uncommon. It exists. All four parameters affect what a user receives, not what the build receives. Setting modextravars does not help a build that needs an environment variable. The module is generated in the module step after the build has completed several earlier steps.

Naming schemes

The transcript path equals modulefiles/chem/QMCPACK/4.4.0-foss-2025a.lua. The chem identifier originates from moduleclass. moduleclass is a category. Other naming schemes exist. Flat is EasyBuild’s default. EasyBuildMNS is the naming scheme. Every module resides in a single directory. Modules follow the name pattern name/version-toolchain-versionsuffix. All modules appear simultaneously in module avail. The system is simple. The system produces long lists. Categorised uses the same names filed under moduleclass. Snellius uses this scheme. Hierarchical is HierarchicalMNS. The toolchain moves from the module name into the path. Loading a compiler changes MODULEPATH. Modules built with that compiler become visible only after the change. Understanding the hierarchical scheme is worthwhile. A site may choose not to use it. A module that cannot be seen remains present. The module lies behind an unloaded toolchain. That corresponds to A toolchain is a hierarchy’s hierarchy implemented as directories. The module system enforces the hierarchy. Discovery then follows a two-step process. Users find it baffling until explained once. --module-naming-scheme sets the scheme. The scheme decides whether the module path is EasyBuildMNS, HierarchicalMNS, or another site scheme.

EB-Module-1 — Where did that line come from

Using the modulefile above:

1. A user runs module whatis QMCPACK/4.4.0-foss-2025a and gets one line. Which easyconfig parameter produced it?

2. They then run module unload QMCPACK and find HDF5 still loaded. Is that a bug?

3. After module load QMCPACK, which of EBROOTQMCPACK, PATH, and LD_LIBRARY_PATH does module show print, and which of those is the prefix the binary was installed under?

4. After module load QMCPACK, echo $EBVERSIONQMCPACK prints 4.4.0. Where did that value come from?

Solution

1 is description, via whatis. Which is the argument for writing a description that reads as a sentence: it is the one line a person who only loads modules ever see about your package.

2 is not a bug. depends_on is reference-counted, so HDF5 stays loaded while anything else still depends on it. If nothing does and it stays, that is worth investigating; if something does, Lmod is doing its job.

3: module show prints EBROOTQMCPACK, the PATH prepend, and LD_LIBRARY_PATH as in the listing on this page. EBROOTQMCPACK is the install prefix.

4 is version, exported as EBVERSIONQMCPACK by the modulefile EasyBuild wrote.

What to remember

• The modulefile is what a user loads. The easyconfig is how it was built.

• modextravars and modluafooter write into that modulefile.

• depends_on names another module, not a version range.