A wrapper is the range EasyBuild will not write

old module name maps to a newer module

A wrapper or .modulerc is the range EasyBuild will not write. The pin in the file stays exact.

a wrapper maps an old name to a newer module

A wrapper is the range EasyBuild will not write.

ModuleRC maps an old name; the recipe still has no range

A wrapper is the range EasyBuild will not write in a recipe. The pin law in RecipeReader is still true.

Questions

  • What does a ModuleRC easyconfig install, if it installs no files?

  • When is a wrapping-dependency the honest answer, and when is it a lie about a pin?

  • What does -D print in EasyBuild 5 if -r is not also passed?

What you will be able to do

  1. Read a ModuleRC easyconfig and say which module name a user loads, and which module actually provides the files.

  2. Tell a wrapping-dependency from a version pin, and say which one A pin is for one generation still forbids in a recipe.

  3. Predict what eb pkg.eb -D lists in EasyBuild 5, versus eb pkg.eb -Dr.

Before this page

A pin covers one generation. It stays applicable to an easyconfig. dependencies list does not contain >=1.14.6. The site already provides HDF5 1.14.6. Many recipes require 1.14.5. Rebuilding those recipes is the pin that matches what was built. An alternative approach uses wrapping. Wrapping resides outside the requesting recipe.

ModuleRC writes a.modulerc and nothing else

The generic ModuleRC easyblock inherits from EasyBlock. The configure, build and install steps are empty. It writes a software-specific .modulerc.

module load HDF5/1.14.5-gompi-2025a

HDF5 1.14.6 loads when the site declares the newer module as a compatible replacement. The extra parameter is check_version, default True; the requested version must be a prefix of the dependency version. Version 1.14.5 may wrap 1.14.5.1. Version 1.14.5 may not wrap 1.15.0 under the default check. This does not create a range in the asking recipe. The asking recipe still names 1.14.5. The site’s module tree responds with a different module. The robot resolving a build still looks for an easyconfig of the pinned version unless wrapping-dependencies is also configured for the build.

wrapping-dependencies is a configuration setting

The wrapping-dependencies setting in EasyBuild lists installations that may satisfy a request for an older version at runtime. It also applies at resolve time when configured. A site uses this to declare that a particular HDF5 version is close enough without editing many files. The same mechanism can be used to misrepresent compatibility when version 1.15 is not considered close enough. The book separates these two facts intentionally. An easyconfig author does not specify a version range. A site operator may apply a wrap. A pin is for one generation’s “no operator, no caret, no tilde” refers to the file. This page addresses the directory tree from which the file is loaded. A wrap that causes a build to resolve against a different HDF5 than the pinned version is a finding rather than a convenience. That binary has not been tested with that module. The per-architecture claim of what “installed” means applies one level higher. A wrap is a distinct installation.

EB-Wrap-1 — Pin, wrap, or rebuild

Three situations. Name the mechanism, and say what a user module load of the old name actually gets.

  1. A recipe lists ('HDF5', '1.14.5'). The site has only 1.14.6. A ModuleRC easyconfig is installed with check_version = True.

  2. The same recipe, no ModuleRC, wrapping-dependencies off.

  3. The site wants every recipe that named 1.14.5 to build against 1.14.6 from now on.

Solution

  1. ModuleRC. module load HDF5/1.14.5-... resolves to the 1.14.6 module.14.5 is a prefix of 1.14.6. The recipe file is unchanged.

  2. The robot does not resolve the build. No 1.14.5 exists module and no wrap. module load of the old name fails.

  3. That is a rebuild, or a wrapping-dependencies configuration that the site accepts as a lie about the pin. The recipe cannot spell that. Changing the pin in the easyconfig and rebuilding is the claim that will survive a move to another site.

EasyBuild 5: -D no longer implies -r

Before EasyBuild 5.0, --dry-run and -D automatically set --robot.

eb GROMACS-2025.2-foss-2025a.eb -D

A full resolved plan was obtained. In version 5.0 that implication was removed. The same command now dry‑runs the named file only. Dependencies are not walked unless -r is also passed:

eb GROMACS-2025.2-foss-2025a.eb -Dr

The robot’s recordings already use -r -D. Both letters appear to request recursive operation (‑r) and debug output (‑D). A reader who omits -r will not obtain recursive behavior. The other dry‑run is --extended-dry-run / -x. It prints the build procedure. That printout does not replace -Dr. The printed procedure may differ from the real run whenever an EasyBlock branches on files that a dry‑run never unpacks.

EB-Dry-1 — What -D prints

EasyBuild 5.4.0, a robot tree that contains the full foss-2025a GROMACS closure. Two commands:

A. eb GROMACS-2025.2-foss-2025a.eb -D
B. eb GROMACS-2025.2-foss-2025a.eb -Dr

  1. What does each print?

  2. Which one is the plan The robot told the reader to read before a non-trivial build?

  3. A colleague says “-D already retains every dependency.” In which EasyBuild generation was that true?

Solution

  1. A prints an overview of the named easyconfig. It does not walk the robot. B prints the resolved closure, short paths.

    1. That is the plan.

  3. EasyBuild 4. In 5.0 the implication was dropped. The colleague is quoting a default that is no longer true.

What to remember

  • An easyconfig still cannot write a range. A ModuleRC .modulerc is how a site answers an old name with a newer module.

  • check_version default True requires the requested version to be a prefix of the wrapped one.

  • In EasyBuild 5, -D does not imply -r. The plan is -Dr.