Afterword: when EasyBuild is the wrong tool

EasyBuild is the wrong tool when the job is a different installer, or no installer.

What EasyBuild is built to be good at

EasyBuild builds software from source reproducibly into a curated generation of exact versions. EasyBuild produces modulefiles for a shared system whose users outnumber its maintainers by a factor of a thousand or more. Exact pins are in A pin is for one generation. Generation timing is in One easyconfig, many installs, and from‑source build costs are in Build your own, without asking anyone. A generation means the whole stack moves at once typically once a year. From-source builds take hours. A site that needs a few hundred extensions and user-defined problems pays that cost on every rebuild. 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. The remainder of this page addresses the drawbacks.

When the answer is a different tool for the same job

Three scenarios provide a genuine alternative rather than a complaint.

A Python environment that changes weekly

Eleven PyPI packages this week, twelve next week, and a different version of one of them the week after, is a weekly cadence. EasyBuild’s generation is annual. An easyconfig, a build, and a module for each of those changes puts the maintainer on the researcher’s week. The fit is module load Python and a venv the researcher owns. pip or uv inside that venv keeps the weekly cadence. The stack still owns the interpreter, the compiler, and the numerical libraries. The weekly packages stay out of the annual generation.

Software that arrives as a container

Some vendors supply only a container image. EasyBuild can wrap a container. That is a different object from a recipe that builds the software.

A stack somebody has already built

EESSI is an optimised stack built with EasyBuild and mounted rather than installed, described in EESSI, somebody else’s stack. Use it to obtain the software. Use EasyBuild to determine the software specification. Keep a local rebuild only for a version required by no other, a site-maintained patch, or a toolchain the site’s users still rely on.

When another packaging system fits the problem better

Spack expresses dependency constraints as ranges and resolves them for each installation (Gamblin et al. [2015]). The expression depends_on('hdf5@1.10:') is 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 can move across environments without a rebuild. Two installations on the same machine may legitimately differ. 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. The choice is 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 gives minutes per environment and identical results on a laptop and a cluster, with binaries built for portability rather than for one instruction set.

A site operating a large machine typically employs more than one of these systems for different user populations. A site that uses more than one of those systems is not failing.

The part that transfers

A pin, a checksum, and a module name are claims. The same questions apply to a Spack spec, a conda pin, and a container tag: what object, which bytes, which environment.

The end of the book

EasyBuild’s design provides exact versions, curated generations, from-source builds and modulefiles for a shared machine with many more users than maintainers. Each of those elements is a trade. A requirement that changes weekly does not belong in an annual generation. Software without source is a runtime to wrap rather than a build to fake. 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. A toolchain decides what your dependencies are allowed to see. A version beside a dependency is an exact pin for one generation and not a minimum. A filename is a query. The answer depends on three lists set in three different places. A checksum concerns 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 exists. There are no version ranges. The framework does not guess. A tool that does not guess shows where the uncertainty actually is. The rest is documentation.