An easystack is the list the bot will build¶

an easystack YAML is the ordered list the bot will build — An easystack is the ordered list the bot feeds to eb. No solve happens here.¶

YAML list the bot will build — An easystack is the list the bot will build, in that order.¶

software, version, toolchain — An easystack is the list the bot will build. Each row is a name, a version, and a toolchain.¶

Questions

What is an easystack file, if it is not a second recipe format?
Which YAML key is stable in EasyBuild 5, and which top-level key is not implemented yet?
How does EESSI decide which EasyBuild version to load for a given file?

What you will be able to do

Read an easystack YAML file and say which eb commands it is equivalent to, including per-item options.
Name the EESSI path and filename a new package belongs in, and say why the EasyBuild version is in the name.
Tell a from-commit entry from a rebuild, and say what each one causes the bot to pass to eb.

Before this page

An easyconfig is Python: an easystack names easyconfigs; it does not replace them.
The robot: --robot is what the bot adds around a new-install easystack.
EESSI, somebody else’s stack: the six-step postcard this page fills in.

An easyconfig defines a single package. A site and EESSI require a list of packages for one toolchain generation, one EasyBuild version, and one repository version. The list is an easystack file: YAML read by EasyBuild with --easystack. EasyBuild 5 marks the format as stable. The format no longer needs --experimental. The file does not introduce a second recipe language. Each item is a filename that the robot already resolves. Extra keys under options: become extra eb flags for that item.

A list of filenames, plus flags without dashes¶

The official shape is shown on EasyBuild’s page.

easyconfigs:
 - PyTorch-1.12.0-foss-2022a-CUDA-11.7.0.eb:
 options:
 from-pr: 15924
 debug: True
 - Hypre-2.25.0-foss-2022a.eb
 - GROMACS-2025.4-foss-2025b.eb:
 options:
 installpath: /my/custom/installpath
 parallel: "1"

That is equivalent to three eb invocations:

eb PyTorch-1.12.0-foss-2022a-CUDA-11.7.0.eb --from-pr 15924 --debug
eb Hypre-2.25.0-foss-2022a.eb
eb GROMACS-2025.4-foss-2025b.eb --installpath /my/custom/installpath --parallel 1

Missing any of the three rules can be costly after a bot job fails. A list marker must be present. YAML lacking the leading list dash does not constitute an easystack. Dashes that form a command-line flag are omitted in the file. from-pr: 15924 corresponds to --from-pr 15924. Short options such as D: True are permitted but discouraged. Certain values must be quoted. YAML converts an unquoted 1 to the boolean True. parallel expects an integer. The file should contain parallel: "1". debug: True illustrates the opposite case. The automatic conversion matches the option’s requirement.

Command-line options come first, and last wins¶

eb --easystack my.yaml --dry-run applies --dry-run to every item. EasyBuild places command-line flags before per-item options from the file. EasyBuild respects the argument that was put last. A file that sets debug: True on one item still enables debug for that item even if the command line said --disable-debug. The opposite does not hold. A flag that exists only on the command line applies to every item. A top-level options: block intended to apply to the whole file is documented as “to be developed” (EasyBuild issues #4105, #4106, #4104, #3512). The documented features include global options, an intended EasyBuild version, dropping --easystack in favour of auto-detection, and labels such as gpu. None of those features are present in 5.4.0. A file that puts robot: True at the top level does not achieve the intended effect. EESSI does not wait for that work. The bot adds --robot (or --rebuild) on the command line once around the whole file. That is the next section.

EESSI puts the EasyBuild version in the filename¶

The EESSI/software-layer repository was split on 2025-06-11. The build scripts reside in EESSI/software-layer-scripts. Remaining content in software-layer consists mainly of easystack files and a 33-line software-layer/bot/build.sh that pins a software-layer-scripts commit. Installations for a specific EESSI version are no longer tracked by a git branch. Tracking now uses the directory:

easystacks/software.eessi.io/<eessi_version>/eessi-<eessi_version>-eb-<eb_version>-<toolchain>.yml

A new entry for GROMACS on the 2025.06 tree, compiled with EasyBuild 5.3.0 and the 2025b generation, belongs in that file:

easystacks/software.eessi.io/2025.06/eessi-2025.06-eb-5.3.0-2025b.yml

The filename selects the EasyBuild version. EESSI-install-software.sh is the installer that loads that module.

eb_version=$(echo ${easystack_file} | sed 's/.*eb-\([0-9.]*\).*.yml/\1/g')
source ${TOPDIR}/load_easybuild_module.sh ${eb_version}

A line added to the 5.3.0 file is built with EasyBuild 5.3.0, even when 5.4.0 is already present on the tree. A new package goes in the file for the current EasyBuild release on that EESSI version. An older file that lists similar software is the wrong place. The 001-system files run first. The 2023.06 README in software-layer states: “Software installed with system toolchain should be installed first, this includes EasyBuild itself.” CUDA easystacks are processed before any components that depend on CUDA. Filename order determines the processing order. The pull request targets main. The previous version branches (2023.06-software.eessi.io and others) have been removed.

from-commit is how an easyconfig not on the robot path gets built¶

The 4 May 2026 webinar presented by Lara Peeters and Kenneth Hoste covers the two cases that actually occur. When the easyconfig is already present in the EasyBuild release that the easystack filename names, the entry is a bare filename. Their scikit-bio 0.7.1 example is referenced.

- scikit-bio-0.7.1.post1-foss-2025a.eb

If the easyconfig exists only in an EasyBuild pull request, the entry includes from-commit (or the older from-pr). The live 2025.06 / EasyBuild 5.3.0 / 2025b file on software-layer shows this for GROMACS 2025.4.

- GROMACS-2025.4-foss-2025b.eb:
options:
# see https://github.com/easybuilders/easybuild-easyconfigs/pull/24956
from-commit: a3bb54895c3de5600fdfd2893a818378daebc7ee

GROMACS 2026.2 on the same file also pulls an easyblock from a commit.

- GROMACS-2026.2-foss-2025b.eb:
options:
# see https://github.com/easybuilders/easybuild-easyconfigs/pull/25879
from-commit: 9320dfe8ae6f45d37edd0ef52be37e7d3668d298
# see https://github.com/easybuilders/easybuild-easyblocks/pull/3531
include-easyblocks-from-commit: cfb6f93bfae8bef5d8996ae6696defcafbf0d4ad

The webinar explicitly states the merge order. The software-layer pull request may be opened while the easyconfig pull request remains open. Deployment to the CernVM-FS repository occurs only after merging the EasyBuild pull request. A from-commit pin is temporary; the merged easyconfig becomes the source of truth. The 2026.06 tree maintains the same shape and reflects a newer generation. The live eessi-2026.06-eb-5.4.0-2026.1.yml opens with OpenMPI and foss-2026.1.eb, which declares the first toolchain generation of a new EESSI version.

EB-Easystack-1 — Which file, and which options

A colleague has a working local install of Octave-11.1.0-foss-2025b.eb on EESSI 2025.06, built with EasyBuild 5.3.0. The easyconfig is already in that EasyBuild release. A second package, scikit-bio-0.7.2-foss-2025b.eb, landed on develop after pull request 25908 (merged 2026-05-14), commit d04690454404aee9d12fc57858c79382adf64d8b.

Which easystack file receives each line?
Write the two YAML items.
The software-layer pull request is opened today. When can the installations be deployed into software.eessi.io?

Solution

Both lines go in easystacks/software.eessi.io/2025.06/eessi-2025.06-eb-5.3.0-2025b.yml. The EasyBuild version in the filename is the one the bot will load. Octave is already on that tree as a bare name; scikit-bio is the from-commit case from the same file.

The live file already contains both, and they look like this:

- Octave-11.1.0-foss-2025b.eb
- scikit-bio-0.7.2-foss-2025b.eb:
options:
# see https://github.com/easybuilders/easybuild-easyconfigs/pull/25908
from-commit: d04690454404aee9d12fc57858c79382adf64d8b

Both can be deployed as soon as the bot has green artefacts on

every supported CPU target. The easyconfig is already on develop.

Rebuilds are a different directory, and a different flag¶

By default, EESSI does not rebuild. A rebuild modifies the bytes behind a module name that users are already loading. If a rebuild is unavoidable, the entry does not go in the ordinary easystack. It is placed in rebuilds/, with a date in the name:

easystacks/software.eessi.io/<ver>/rebuilds/YYYYMMDD-eb-<eb_version>-<name>-<short-reason>.yml

A live example from 2025.06. 21 June 2026, rebuilding Rust to pick up an RPATH fix that landed in EasyBuild 5.3.1:

# rebuild Rust/1.91.1-GCCcore-14.3.0, to fix RPATH linking
# see https://github.com/easybuilders/easybuild-easyconfigs/issues/26232
# fixed in EasyBuild v5.3.1, see https://github.com/easybuilders/easybuild-easyblocks/pull/4156
easyconfigs:
 - Rust-1.91.1-GCCcore-14.3.0.eb

The EESSI-install-software.sh script splits changed YAML files of the pull request into two lists. The EESSI-install-software.sh script iterates both lists and passes --rebuild only when the path contains /rebuilds/.

if [[ ${easystack_file} == *"/rebuilds/"* ]]; then
 ${EB} --easystack ${easystack_file} --rebuild
else
 ${EB} --easystack ${easystack_file} --robot
fi

The directory is the flag. Placing a rebuild in the ordinary easystack file does not cause --rebuild to be passed, and EasyBuild will not overwrite an existing installation. Placing a new package in rebuilds/ passes --rebuild and bypasses the robot. That is the incorrect command for a package that has not yet been added. The comments at the top of a rebuild file are the bill of materials. They say what was rebuilt, why, and which issue or pull request required it. The CUDA 12.1.1 rebuild from May 2024 is the documented template, including accept-eula-for: CUDA under options:.

How the bot finds the file at all¶

The bot ignores tickets and commit messages when deciding what to build. EESSI-install-software.sh scans the pull request .diff for new or modified YAML files in easystacks/. The script excludes the CUDA helper easystacks in scripts/gpu_support/. Only files whose paths match the repository and the EESSI version for which the job builds are retained.

changed_easystacks=$(cat ${pr_diff} | grep '^+++' | cut -f2 -d' ' \
 | sed 's@^[a-z]/@@g' | grep 'easystacks/.*yml$' \
 | egrep -v 'known-issues|missing' \
 | (grep -v "scripts/gpu_support/" || true))

EB-Easystack-2 — What the bot will type

A pull request against EESSI/software-layer main adds one file:

easystacks/software.eessi.io/2025.06/rebuilds/20260911-eb-5.3.1-OpenMPI-ofi-fix.yml

The file contains a single item, OpenMPI-5.0.8-GCC-14.3.0.eb, with no options:. The job is building EESSI 2025.06 for x86_64/amd/zen4.

Which EasyBuild version is loaded, and from where is that decided?
What is the eb command the install script will run?
The same pull request also adds a line to eessi-2025.06-eb-5.3.1-2025b.yml. In which order are the two files processed, and why does the order matter?

Solution

EasyBuild 5.3.1. The sed in EESSI-install-software.sh pulls the version out of eb-5.3.1 in the filename. The EESSI version in the path only decides whether this job considers the file.
eb --easystack <that rebuilds file> --rebuild. The /rebuilds/ component is what selects --rebuild over --robot.
Rebuilds first, then new-install files. A rebuild that is meant to replace an OpenMPI the new-install file then depends on has to land before the dependent is planned. The script says so: “first process rebuilds, if any, then easystack files for new installations”.

sourcesWhere this page comes from

EasyBuild, docs last update 2026-08-09:

Easystack files: the easyconfigs: key, per-item options:, quoting, last-wins, and the four “to be developed” issues.

EESSI talks, read 2026-09-11:

Lara Peeters and Kenneth Hoste, Building software on top of EESSI + contributing to EESSI, MultiXscale webinar, 2026-05-04 (EESSI-webinars-spring-2026-building-contributing-2026-05-04.pdf): the six contributing steps, from-commit while the EasyBuild pull request is open, deployment waits on merge.
Caspar van Leeuwen, Bob Dröge and Pedro Santos Neves, Using EESSI as a base for a central software stack, MultiXscale webinar, 2026-06-01: a site repo uses the same easystack path shape, easystacks/<site_cvmfs_repo>/<EESSI_VERSION>/.

Code, EESSI/software-layer and EESSI/software-layer-scripts, main, read 2026-09-11: easystacks/software.eessi.io/2025.06/eessi-2025.06-eb-5.3.0-2025b.yml, easystacks/software.eessi.io/2026.06/eessi-2026.06-eb-5.4.0-2026.1.yml, easystacks/software.eessi.io/2025.06/rebuilds/20260621-eb-5.3.1-rebuild-Rust-1.91.yml, EESSI-install-software.sh (the .diff grep and the --rebuild / --robot split).

Docs: opening a pull request, including the 2025-06-11 split and the rebuild naming convention.

What to remember

An easystack is a YAML list of easyconfig filenames. Per-item options: become eb flags with the dashes stripped, and last-wins means those flags beat the command line.
EESSI’s path is easystacks/software.eessi.io/<ver>/eessi-<ver>-eb-<ebver>-<tc>.yml. The EasyBuild version in the name is the module the bot loads.
from-commit (or from-pr) is how an easyconfig that is not yet the default robot path is built. After a merge the pin can drop.
A rebuild lives under rebuilds/ and is the only case that passes --rebuild instead of --robot.