A wrapper is the range EasyBuild will not write

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 chapter

  • A pin is for one generation: a dependency version is a pin. This chapter is the site-side escape.

  • The robot: -D is how a plan is read. EasyBuild 5 changed what that flag implies.

A pin is for one generation remains applicable to an easyconfig. A dependencies list does not contain >=1.14.6. The site already provides HDF5 1.14.6 while many recipes require 1.14.5. Rebuilding those recipes constitutes the honest pin. An alternative approach is wrapping, which 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

Loads HDF5 1.14.6 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 constitute 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, not a syntax

The wrapping-dependencies setting in EasyBuild lists installations that may satisfy a request for an older version at runtime (and, when configured, at resolve time). 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 chapter 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 constitutes a finding rather than a convenience. That binary has not been tested with that module. What “installed” means’s per-architecture claim applies one level higher: a wrap represents 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. There is no 1.14.5 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. It is not something the recipe can spell. 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

Prior to EasyBuild 5.0, --dry-run / -D automatically set --robot. A reader who entered.

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. The prose must explain why both letters are present. A reader who omits -r. --extended-dry-run / -x is the other dry‑run. It prints the build procedure. It is not a substitute for -Dr, and the procedure it prints 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.

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

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.