Move supported toplevel toolchains from eb_hooks.py into a separate JSON for easier define-once-and-reuse by casparvl · Pull Request #312 · EESSI/software-layer-scripts

casparvl · 2026-10-01T16:23:37Z

Move supported toplevel toolchains from `eb_hooks.py` into a separate JSON file

The toplevel toolchains supported per EESSI version (EESSI_SUPPORTED_TOP_LEVEL_TOOLCHAINS) are defined inside eb_hooks.py. Other scripts that need this list (e.g. the native compiler flags check in #311 ) would have to parse or import the hooks file, and importing it requires EasyBuild. This PR moves the list into eessi_supported_toolchains.json, so the list stays in one place and any script can read it.

eessi_supported_toolchains.json sits next to eb_hooks.py, and install_scripts.sh installs it next to it in <prefix>/init/easybuild/. eb_hooks.py locates it relative to its own file. This works regardless of whether the eb_hooks.py file is used from it's installed location in the CVMFS repo, or from a clone of the software-layer-scripts repository, since every EasyBuild version in use loads the hooks via importlib's spec_from_file_location, which sets __file__. If the file can't be found or parsed, an EasyBuildError names the expected location.
Toolchains that need a minimum EasyBuild version (lfoss/2025b from 5.2.0, rompi/2025a from 5.3.1) have a min_easybuild_version field instead of being appended conditionally in code.
CI: test-eb-hooks.yml also checks that the deployed eessi_supported_toolchains.json matches the repo, like the existing check for eb_hooks.py.

Testing done (by AI). Loaded through EasyBuild's own hooks loader, EESSI_SUPPORTED_TOP_LEVEL_TOOLCHAINS is identical before and after this change under EasyBuild 4.9.4, 5.2.1 and 5.4.0, which covers both version guards. With eb --stop fetch in EESSI 2025.06 (EasyBuild 5.4.0), the toolchain check still accepts M4-1.4.19-GCCcore-14.2.0 and CDO-2.5.3-lompi-2025b, and rejects M4-1.4.19-GCCcore-12.3.0. That holds both for the repo's eb_hooks.py and for a copy installed with install_scripts.sh into a scratch prefix.

Note: anyone pointing EASYBUILD_HOOKS at their own copy of eb_hooks.py now needs eessi_supported_toolchains.json next to it.

Deploy required

Note that since this PR changes eb_hooks.py, it needs to be deployed (only once per EESSI version, I believe, since it's installed into <EESSI_VERSION>/init/easybuild).

AI disclosure

This change was made with an AI coding assistant (Claude, via Claude Code), as a spin-off of the native compiler flags check PR (#311). I asked for the supported-toolchains list to be moved out of eb_hooks.py into an easily parseable file used by both eb_hooks.py and the new check, with the requirement that it works both from a clone of this repository and from the copy installed in CVMFS.

The assistant:

checked in the EasyBuild source how the hooks file is loaded;
implemented the change;
verified it as described above, recording the old behaviour before changing anything.

At my request it then split this off from the larger PR into this preparatory one. I reviewed the result before opening this PR.

🤖 Generated with Claude Code

…SON file The supported toplevel toolchains per EESSI version are now defined in eessi_supported_toolchains.json rather than in eb_hooks.py itself, so that they can also be used by other scripts without having to parse (or import) the hooks file. - eessi_supported_toolchains.json is located next to eb_hooks.py, both in the repository and when installed in <prefix>/init/easybuild/ by install_scripts.sh. eb_hooks.py locates it relative to its own location. - Toolchains that can only be installed with a recent enough EasyBuild version (lfoss/2025b, rompi/2025a) now specify 'min_easybuild_version' instead of being appended conditionally in eb_hooks.py. - CI also checks that the deployed eessi_supported_toolchains.json is up-to-date, like is done for eb_hooks.py. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

trz42

Small and simple change.

Find it a little unsatisfactory for being generated by an AI-assistant:

duplicated code in the test (and name of test file is a bit off now)
it could have added some unit tests for the function and JSON format
would have been nice with some specific instructions on how this was tested (command log)
PR title is repeated in the PR description

trz42 · 2026-10-01T16:58:41Z

 # Copy over EasyBuild hooks file used for installations
 hook_files=(
    eb_hooks.py
+    eessi_supported_toolchains.json


Does it belong here?

Maybe it could be here, but then the name hook_files is a little off. Maybe easybuild_init_files is fitting.

trz42 · 2026-10-01T17:06:25Z

              module load EESSI-extend
              diff "$TEMP_FILE" "$EASYBUILD_HOOKS"

+        - name: Check whether eessi_supported_toolchains.json (used by eb_hooks.py) is up-to-date


Essentially the same as the check for eb_hooks.py? If so could we use another matrix variable for the files to be checked?

trz42 · 2026-10-01T17:10:32Z

+            toolchains = json.load(fh)
+    except (OSError, ValueError) as err:
+        raise EasyBuildError(f"Failed to load supported toolchains from {toolchains_file} "
+                             f"(it is expected to be located next to the EasyBuild hooks file): {err}")


Maybe the text in parantheses is a little speculative as you also show this for ValueError?

trz42 · 2026-10-01T17:13:12Z

+    Load the supported top-level toolchains per EESSI version from eessi_supported_toolchains.json,
+    which is located next to this hooks file (both in the software-layer-scripts repository, and when installed
+    in <EESSI prefix>/init/easybuild). Toolchains that require a more recent EasyBuild version than the one
+    being used (as specified via 'min_easybuild_version') are left out.


Maybe add

Returns: supported_toolchains (dict)

trz42 · 2026-10-01T17:20:14Z

+    in <EESSI prefix>/init/easybuild). Toolchains that require a more recent EasyBuild version than the one
+    being used (as specified via 'min_easybuild_version') are left out.
+    """
+    toolchains_file = os.path.join(os.path.dirname(os.path.realpath(__file__)), 'eessi_supported_toolchains.json')


How about specifying the location via an environment variable? Inferring the location from the location of eb_hooks.py could be a fallback if the environment variable is not set.

casparvl mentioned this pull request Oct 1, 2026

Check native compiler flags against per-CPU-target references before building #311

Draft

trz42 reviewed Oct 1, 2026

View reviewed changes

Navigation Menu

Move supported toplevel toolchains from eb_hooks.py into a separate JSON for easier define-once-and-reuse - #312

Move supported toplevel toolchains from eb_hooks.py into a separate JSON for easier define-once-and-reuse#312
casparvl wants to merge 1 commit into
EESSI:mainfrom
casparvl:separate-supported-toolchains

casparvl commented Oct 1, 2026 •

edited

Loading

Uh oh!

trz42 left a comment

Uh oh!

trz42 Oct 1, 2026

Uh oh!

trz42 Oct 1, 2026

Uh oh!

trz42 Oct 1, 2026

Uh oh!

trz42 Oct 1, 2026

Uh oh!

trz42 Oct 1, 2026

Uh oh!

trz42 Oct 1, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

casparvl commented Oct 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Move supported toplevel toolchains from eb_hooks.py into a separate JSON file

AI disclosure

Uh oh!

trz42 left a comment

Choose a reason for hiding this comment

Uh oh!

trz42 Oct 1, 2026

Choose a reason for hiding this comment

Uh oh!

trz42 Oct 1, 2026

Choose a reason for hiding this comment

Uh oh!

trz42 Oct 1, 2026

Choose a reason for hiding this comment

Uh oh!

trz42 Oct 1, 2026

Choose a reason for hiding this comment

Uh oh!

trz42 Oct 1, 2026

Choose a reason for hiding this comment

Uh oh!

trz42 Oct 1, 2026

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

casparvl commented Oct 1, 2026 •

edited

Loading

Move supported toplevel toolchains from `eb_hooks.py` into a separate JSON file