Afterword: when EasyBuild is the wrong tool

This chapter contains no widgets and no parameters. It argues against the subject of every other chapter.

What EasyBuild is built to be good at

EasyBuild builds software from source, reproducibly, into a curated generation of exact versions. It produces modulefiles for a shared system whose users outnumber its maintainers by three or four orders of magnitude. Exact pins, generation timing, and from‑source build costs are covered respectively in A pin is for one generation, One easyconfig, many installs, and Build your own, without asking anyone. A generation means the whole stack moves at once, typically once a year. From‑source builds take hours, translating into a few hundred extensions and user‑defined problems. Modulefiles make the artifact an environment rather than a copyable directory. These trade‑offs suit a national supercomputer serving thousands of users. They are unsuitable in many other contexts, and the remainder of this chapter addresses the drawbacks.

When the answer is a different tool for the same job

Three scenarios, each offering a genuine alternative instead of a complaint.

A Python environment that changes weekly

Eleven packages from PyPI are required, with twelve needed the following week and a different version of one required the week after. Using EasyBuild requires an easyconfig for each change, a build for each easyconfig, and a module for each result. The stack’s generation is pinned to annual changes while requirements change weekly, preventing alignment. The appropriate solution is a Python module provided by EasyBuild combined with a virtual environment owned by the researcher. Invoking pip or uv within a venv after module load Python supplies the weekly cadence and retains control of the interpreter, compiler, and numerical libraries within the stack. Components needing reproducibility receive it, while components needing speed receive performance. The failure mode of handling everything within EasyBuild is not lack of functionality but that a maintainer becomes the bottleneck for another’s research week.

Software that arrives as a container

Certain vendors provide only a container image. There is no source, no configure script, and no method to represent the contents as an easyconfig without distortion.

Apptainer or a comparable runtime is the tool, and a minimal module that configures the invocation constitutes a sensible EasyBuild contribution. Encapsulating the entire image in an easyconfig to resemble a build conveys false information to subsequent readers.

A stack somebody has already built

EESSI, somebody else’s stack describes that case in detail: EESSI, an optimised stack built with EasyBuild and mounted rather than installed. Use it when the goal is obtaining the software. Use EasyBuild when the goal is determining what the software should be. This implies a version that no one else requires, a patch maintained by the site, and a toolchain on which users rely.

When another packaging system fits the problem better

Two systems address a similar problem with different trade‑offs, and the comparison should be stated precisely. Spack expresses dependency constraints as ranges and resolves them for each installation (Gamblin et al. [2015]). The expression depends_on('hdf5@1.10:') represents a real lower bound. A concretiser selects a version that satisfies all such bounds, with variants chosen at install time. That approach contrasts with the trade described in A pin is for one generation. Spack’s format can retain the constraint that the software actually possesses. A package to move across environments without modification. two installations on the same machine may legitimately differ, and reproducing a result requires recording the resolved graph instead of naming a generation. conda-forge distributes binaries and performs solving over a channel. Installation is a download and a solve rather than a build. This yields a working environment in minutes, identical on a laptop and on a cluster. In return, those binaries are built for portability rather than for a specific machine’s instruction set. Exploiting a specific instruction set is the purpose of an HPC stack. Thus the question is not which system is best. It concerns which cost is acceptable.

• EasyBuild provides exact versions, one stack per generation, tuned builds, hours per package, one generation per year, and a maintainer in the loop.

• Spack offers real version ranges, per‑install resolution, tuned builds, hours per package, and a resolved graph that must be captured to reproduce.

• conda-forge delivers minutes per environment, identical results on a laptop and a cluster, and binaries built for portability rather than for the instruction set already paid for.

A site operating a large machine typically employs more than one of these systems for different user populations. This represents a sound arrangement rather than an admission of defeat.

The part that transfers

When applying a concept from this book to another packaging system, prioritize the questions over the parameters. An easyconfig is Python’s question is “what does this name imply that the file does not say”. Each packaging system provides an answer, often longer than an initial guess. A toolchain is a hierarchy’s question is “what is this dependency allowed to see”. The robot’s question is “where is the tool looking, and in what order”. A checksum is a claim about bytes’s question is “what exactly does this checksum claim”. A hook changes a file you are not reading’s question is “is the file on disk the whole input”. None of those constitute EasyBuild questions. EasyBuild provides particularly crisp answers. It a suitable subject for learning to ask those questions.

The end of the book

EasyBuild’s design is exact versions, curated generations, from-source builds and modulefiles, for a shared machine whose users vastly outnumber its maintainers. Every one of those is a trade.

A requirement that changes weekly does not belong in an annual generation. Software with no source is a runtime to wrap rather than a build to fake. And a stack needed only to have already exists.

What survives all of that is a habit of asking what a thing actually says.

An easyconfig says less than it appears to. A toolchain is not a label but the top of a computed hierarchy, and it decides what your dependencies are even allowed to see. A version beside a dependency is an exact pin for one generation and not a minimum. A filename is a query, and the answer depends on three lists set in three different places. A checksum is about bytes and nothing else. A green build describes one tree on one machine.

None of those are EasyBuild questions. EasyBuild is a good place to learn them. No default easyblock, no version ranges, no guessing. A tool that does not guess is showing where the uncertainty actually is.

Take that, and the rest is documentation.