Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 5 additions & 3 deletions docs/blog/posts/2026/01/Spack-on-top-of-EESSI-PoC.md
Original file line number Diff line number Diff line change
Expand Up @@ -28,7 +28,7 @@ and leveraging software installations from EESSI for all required dependencies,

### Step 1: A Spack database for EESSI

To get started, we created an external *Spack database* using the [`spack.database.Database` class](https://spack.readthedocs.io/en/latest/spack.html#module-spack.database)
To get started, we created an external ("upstream") *Spack database* using (a modded version of) the [`spack.database.Database` class](https://spack.readthedocs.io/en/latest/spack.html#module-spack.database)
that Spack provides, which exposes software installed in EESSI to Spack.

This was done through a Python script, and only for a small set of hand-picked software
Expand All @@ -38,7 +38,7 @@ Using `spack find`, we can check whether Spack is aware of these installations:

![Spack database for software installations included in EESSI](spack-eessi-20251106-001.webp)

Looks good so far...
The `[^]` symbol indicates a package that is provided by our custom "upstream" database. Looks good so far...


### Step 2: Checking required dependencies for QuantumESPRESSO
Expand All @@ -53,7 +53,7 @@ When done correctly, we can see that all required dependencies are indeed resolv
![Checking required dependencies with `spack spec`](spack-eessi-20251106-002.webp)

Here, we use `@7.4.1` to specify the QuantumESPRESSO version we want to install,
and `~mpi` to ensure that the QuantumESPRESSO installation will have MPI support.
and `~mpi` to disable MPI support, for the sake of this simple exercise.


### Step 3: Installing QuantumESPRESSO with Spack
Expand Down Expand Up @@ -90,5 +90,7 @@ but this is a nice first step...
This work is being done in collaboration with members of the Spack development team,
including Todd Gamblin and Massimiliano Culpo.

The code and scripts developed for this proof-of-concept are available in the [EasySpack repository](https://github.com/lorisercole/easyspack). See "Approach #2 [legacy]" in the README for implementation details.

For updates, check the [dedicated support issue](https://gitlab.com/eessi/support/-/issues/170)
that was opened on using Spack on top of EESSI, or stay tuned for future blog posts!
152 changes: 152 additions & 0 deletions docs/blog/posts/2026/02/Spack-on-top-of-EESSI-best-of-both-worlds.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,152 @@
---
authors: [lorisercole]
date: 2026-02-05
slug: Spack-on-top-of-EESSI-best-of-both-worlds
---

# Using Spack on Top of EESSI: Best of Both Worlds

<figure markdown="span">
![Spack + EESSI](../01/spack-plus-eessi.webp){width=75%}
</figure>

The HPC software landscape offers powerful tools for managing scientific software, such as [EasyBuild](https://easybuild.io) and [Spack](https://spack.io).

[EESSI](https://www.eessi.io) provides a ready-to-use software stack with thousands of optimized packages built with EasyBuild.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[EESSI](https://www.eessi.io) provides a ready-to-use software stack with thousands of optimized packages built with EasyBuild.
[EESSI](https://www.eessi.io) provides a ready-to-use software stack with thousands of optimized software installations that were built with EasyBuild.


Imagine you are working on an HPC system with EESSI already available. You have access to a wealth of optimized scientific software packages, libraries, tools, as well as compilers. But you need to install a new tool or a specific version of a package that's not in EESSI yet.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Imagine you are working on an HPC system with EESSI already available. You have access to a wealth of optimized scientific software packages, libraries, tools, as well as compilers. But you need to install a new tool or a specific version of a package that's not in EESSI yet.
Imagine you are working on an HPC system with EESSI already available. You have access to a wealth of optimized installations for scientific software packages, libraries, tools, as well as compilers. But you need to install a new tool or a specific version of a package that's not in EESSI yet.


You can already extend EESSI with new software through the [EESSI-extend](https://www.eessi.io/docs/using_eessi/building_on_eessi/#building-software-on-top-of-eessi-with-easybuild) module.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use internal link:

Suggested change
You can already extend EESSI with new software through the [EESSI-extend](https://www.eessi.io/docs/using_eessi/building_on_eessi/#building-software-on-top-of-eessi-with-easybuild) module.
You can already extend EESSI with new software through the [EESSI-extend](../../../../using_eessi/building_on_eessi.md) module.

This utility provides you with a pre-configured EasyBuild installation that you can use to build packages from [EasyConfig files](https://docs.easybuild.io/terminology/#easyconfig_files).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This utility provides you with a pre-configured EasyBuild installation that you can use to build packages from [EasyConfig files](https://docs.easybuild.io/terminology/#easyconfig_files).
This utility provides you with a pre-configured EasyBuild installation that you can use to build packages from [easyconfig files](https://docs.easybuild.io/terminology/#easyconfig_files).


Like EasyBuild, [Spack](https://spack.io) is a flexible build tool that also offers a vast repository of build recipes maintained by a large and active community, making it a familiar tool for many HPC users.
By enabling Spack to leverage packages already available in EESSI as dependencies, we can offer users the best of both worlds: the convenience of a pre-built, optimized software stack combined with the flexibility to quickly build new packages using tools they already know.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
By enabling Spack to leverage packages already available in EESSI as dependencies, we can offer users the best of both worlds: the convenience of a pre-built, optimized software stack combined with the flexibility to quickly build new packages using tools they already know.
By enabling Spack to leverage software installations already available in EESSI as dependencies, we can offer users the best of both worlds: the convenience of a pre-built, optimized software stack combined with the flexibility to quickly build new packages using tools they already know.


<!-- more -->


In a previous [blog post](https://www.eessi.io/docs/blog/2026/01/09/Spack-on-top-of-EESSI-PoC/), we presented a first proof-of-concept implementation of this vision.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use internal links

Suggested change
In a previous [blog post](https://www.eessi.io/docs/blog/2026/01/09/Spack-on-top-of-EESSI-PoC/), we presented a first proof-of-concept implementation of this vision.
In a previous [blog post](../01/Spack-on-top-of-EESSI-PoC.md), we presented a first proof-of-concept implementation of this vision.

We used a custom-built upstream database to make Spack aware of EESSI's software stack and managed to build a new Quantum ESPRESSO installation that reused dependencies from EESSI.

Thanks to recent updates to Spack (in particular, treating externals as concrete specs and allowing the definition of dependencies – see [this PR](https://github.com/spack/spack/pull/51118)) and an active collaboration with its developers, it is now possible to connect Spack and EESSI in a *seamless* and *Spack-native* way.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Thanks to recent updates to Spack (in particular, treating externals as concrete specs and allowing the definition of dependencies – see [this PR](https://github.com/spack/spack/pull/51118)) and an active collaboration with its developers, it is now possible to connect Spack and EESSI in a *seamless* and *Spack-native* way.
Thanks to recent updates to Spack (in particular, treating externals as concrete specs and allowing the definition of dependencies – see [this pull request in Spack](https://github.com/spack/spack/pull/51118)) and an active collaboration with its developers, it is now possible to connect Spack and EESSI in a *seamless* and *Spack-native* way.


## How it works

Spack 1.1+ introduces external packages treated as concrete specs (i.e. like any other spec), with dependency support, allowing us to expose EESSI packages as externals along with their dependencies.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Spack 1.1+ introduces external packages treated as concrete specs (i.e. like any other spec), with dependency support, allowing us to expose EESSI packages as externals along with their dependencies.
Spack 1.1+ introduces external packages treated as concrete specs (i.e. like any other spec), with dependency support, allowing us to expose software installed in EESSI as externals along with their dependencies.

This is the proper, *Spack-onic* way to achieve our goal, and it does not require any modification of Spack's source code, nor the creation of a custom database.

!!! note

Currently we need to add a small patch to Spack to make sure its compiler wrapper works correctly
with the unusual sysroot configuration of EESSI. This is a known
[issue](https://github.com/spack/spack/issues/51582) that will be addressed in future Spack releases.)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
[issue](https://github.com/spack/spack/issues/51582) that will be addressed in future Spack releases.)
[issue](https://github.com/spack/spack/issues/51582) that will be addressed in future Spack releases.


We implement the following workflow to connect Spack to EESSI, and build a new Quantum ESPRESSO with Spack reusing EESSI packages as dependencies.


### Step 1 – EESSI software-layer builds
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Step 1 – EESSI software-layer builds
### Step 1 – External packages for EESSI software layer


Declare EESSI software-layer builds as [external packages](https://spack.readthedocs.io/en/latest/packages_yaml.html#external-packages) in a `packages.yaml` configuration file with [external dependencies](https://spack.readthedocs.io/en/latest/packages_yaml.html#specifying-dependencies-among-external-packages).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Declare EESSI software-layer builds as [external packages](https://spack.readthedocs.io/en/latest/packages_yaml.html#external-packages) in a `packages.yaml` configuration file with [external dependencies](https://spack.readthedocs.io/en/latest/packages_yaml.html#specifying-dependencies-among-external-packages).
Declare software installations in EESSI software layer as [external packages](https://spack.readthedocs.io/en/latest/packages_yaml.html#external-packages) in a `packages.yaml` configuration file with [external dependencies](https://spack.readthedocs.io/en/latest/packages_yaml.html#specifying-dependencies-among-external-packages).


![Example packages.yaml of software installations included in EESSI](spack-eessi-20260205-001.webp)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not make this a code block, so people can copy-paste?

Suggested change
![Example packages.yaml of software installations included in EESSI](spack-eessi-20260205-001.webp)
```yaml
# Example ...
packages:
```


*Variants* (e.g. `~mpi+openmp`) should be specified to the best of our knowledge. By default, Spack will fill in the gaps with the package's default variants.

*Link* and *runtime dependencies* should be specified whenever possible. Pure build dependencies are not needed (the only exception being the *compiler*, Spack can reuse this information). A dependency spec should unambiguously point to another declared external package. If an ambiguity exists, Spack will throw an error.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
*Link* and *runtime dependencies* should be specified whenever possible. Pure build dependencies are not needed (the only exception being the *compiler*, Spack can reuse this information). A dependency spec should unambiguously point to another declared external package. If an ambiguity exists, Spack will throw an error.
*Link* and *runtime dependencies* should be specified whenever possible. Pure build dependencies are not needed (the only exception being the *compiler*, since Spack can reuse this information). A dependency spec should unambiguously point to another declared external package. If an ambiguity exists, Spack will throw an error.


Many packages in EESSI depends on packages of the compatibility layer (e.g. `zlib`), that were filtered out during the build process. To detect these packages, see the [next step](#step-2-optional-suggested-eessi-compat-layer).

Anyway, software packages in EESSI are always RPATH-ed to their dependencies, so in most real-case scenarios linking will likely work even if you forget to declare some dependencies.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Anyway, software packages in EESSI are always RPATH-ed to their dependencies, so in most real-case scenarios linking will likely work even if you forget to declare some dependencies.
Since software installations in EESSI are always RPATH'ed to their dependencies, linking will likely work in most real-case scenarios even if you forget to declare some dependencies.



### Step 2 – (optional, suggested) EESSI compat-layer
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
### Step 2 – (optional, suggested) EESSI compat-layer
### Step 2 – (optional, suggested) EESSI compatibility layer


It is possible to detect OS packages available under the EESSI compat-layer and configure Spack to use them as externals.
In EESSI, these packages are often dependencies of software-layer packages (see previous example), so it is suggested to include them.
Comment on lines +64 to +65
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
It is possible to detect OS packages available under the EESSI compat-layer and configure Spack to use them as externals.
In EESSI, these packages are often dependencies of software-layer packages (see previous example), so it is suggested to include them.
It is possible to detect software installations available in the EESSI compatibility layer and configure Spack to use them as externals.
In EESSI, these are often dependencies of software installations in the software layer (see previous example), so it is suggested to include them.


This can be done automatically via `spack external find`:

![Detect compat-layer packages with spack external find](spack-eessi-20260205-002.webp)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This could also be a small asciinema box.

Big advantage here is that you can see it "move", but also that you can copy-paste from it...



### Step 3 – Show configured externals

Externals can then be listed via `spack find --show-configured-externals`.
These packages will get reused during Spack solves by default.

![Show configured externals](spack-eessi-20260205-003.webp)


### Step 4 – Build a new Quantum ESPRESSO with Spack

We can now build new packages with Spack, reusing EESSI installations as dependencies!
Let's try this out by building a new Quantum ESPRESSO with Spack.

We first check what the concretizer comes up with, using `spack spec`:

![Spack spec for quantum-espresso](spack-eessi-20260205-004.webp)

Looks good! Spack is reusing EESSI packages as external dependencies.
It only needs to build the new `quantum-espresso` itself and a few Spack-specific packages: `compiler-wrapper` that is Spack's compiler wrapper, and `gcc-runtime` that is a local copy of the GCC runtime libraries that are provided by EESSI's `gcc@13.2.0`.

Finally, we can proceed with the installation with `spack install quantum-espresso~mpi`:

![Installing Quantum ESPRESSO with Spack on top of EESSI](spack-eessi-20260205-006.webp)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also here we can use asciinema, and just play it at 10x speed... :)



### Step 5 – Verify and run Quantum ESPRESSO

Finally, we can verify that the new Quantum ESPRESSO installation works correctly by running it:

![Running Quantum ESPRESSO installed with Spack](spack-eessi-20260205-005.webp)

When we inspect the `pw.x` binary, we can see that it links to libraries provided by EESSI:

![Inspecting the list of libraries that `pw.x` binary links to](spack-eessi-20260205-007.webp)

(the only exception being `libgomp`, `libgfortran`, `libgcc_s` which come from the `gcc-runtime` package that Spack installs).


## Demo code

A demonstrated implementation of the presented approach is now available in the [EasySpack repository](https://github.com/lorisercole/easyspack).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there are copyright issues with that repo name (I believe @tgamblin mentioned something like this a while ago), might be best to change it already before we publish.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uh, I did not remember it! Let's wait for @tgamblin to confirm.
In case I can change it to something like EessiSpack (and I'll need to change some code... 😅)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it is more about the Spack in the name due to HPSF and copyright

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah basically they don't want Spack in the name -- to avoid confusion with Spack itself (which one should I use? EasySpack or Spack? Sure sounds like the first one's better). LF trademark policy is here if you are interested: https://lfprojects.org/policies/trademark-policy/

So... yeah... it would be good to change the name. Sorry I realize that is a pain. Some alliterative ideas:

  • Spoke (spokes out from the central EESSI hub to enable Spack)
  • Spanner (spans two ecosystems)
  • Spork (serves two functions)

Or less alliterative:

  • PELT - Package Ecosystem Linking Tool
  • PLATO - Package Linking Atlantic Treaty Organization

I think I should stop with that one. I'll see myself out. I guess you could also call it the "EESSI connector for Spack" or something like that, which is boring but straight from the trademark policy. I feel like there has to be a cool name for this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could also just name the repo Spack-on-top-of-EESSI, since that's exactly what it is, no trademark violation there imho.

I LOL'ed at Spork, that's just too good :D

Copy link

@tgamblin tgamblin Feb 5, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that actually runs afoul of the policy b/c it's not spack -- you can call your thing "X for spack", "X compatible with Spack", etc. but not "Spack". There are examples in the policy. If the LF mark is the primary noun it's dicey.


A simple [example script](https://github.com/lorisercole/easyspack/blob/develop/quick_start.sh) showcases the workflow.
It only requires a running EESSI environment and a patched Spack installation (see instructions in the [README](https://github.com/lorisercole/easyspack/blob/develop/README.md)).

<details>
<summary>Example output of `quick_start.sh`</summary>

<figure>
<img src="../../easyspack-demo-1.webp" alt="Output of quick_start.sh" />
</figure>
<figure>
<img src="../../easyspack-demo-2.webp" alt="Output of quick_start.sh" />
</figure>
<figure>
<img src="../../easyspack-demo-3.webp" alt="Output of quick_start.sh" />
</figure>

</details>


## Conclusions and outlook

The workflow we presented is a simple demonstration of how Spack can be integrated with EESSI to leverage its optimized software stack.
More complex scenarios, like building MPI-enabled packages and pre-configured toolchains, are being actively explored.

A complete integration of Spack with EESSI will require building some automation around the generation of the `packages.yaml` files to keep them in sync with EESSI updates, as well as further testing and validation of various build scenarios.

Such an integration will open powerful workflows for HPC users and administrators, allowing new software to be built quickly on top of EESSI's stable, optimized base by leveraging either Spack or EasyBuild.

The future of HPC software management is not about choosing between distributions and package managers: it is about making them work together seamlessly.

---

### Learn more and get involved

We encourage you to join the discussion on the `#spack` channel of [EESSI Slack](https://join.slack.com/t/eessi-hpc/shared_invite/zt-2wg10p26d-m_CnRB89xQq3zk9qxf1k3g) and share your experiences and suggestions!
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use template for Slack URL, since we'll need to change it in the future (it expires)

Suggested change
We encourage you to join the discussion on the `#spack` channel of [EESSI Slack](https://join.slack.com/t/eessi-hpc/shared_invite/zt-2wg10p26d-m_CnRB89xQq3zk9qxf1k3g) and share your experiences and suggestions!
We encourage you to join the discussion on the `#spack` channel of [EESSI Slack]({{ config.extra.slack_invite_url }}) and share your experiences and suggestions!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe also mention Happy Hour sessions here?

https://www.eessi.io/docs/training-events/happy-hours-sessions/


### Acknowledgements

This work was made possible thanks to the collaboration with the Spack development team, in particular Todd Gamblin and Massimiliano Culpo, as well as EESSI team members Kenneth Hoste and Alan O'Cais.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bonus points if you link these to GitHub profiles ;-)

Binary file added docs/blog/posts/2026/02/easyspack-demo-1.webp
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not going to block the publication of the blog post for this, but we should consider using asciinema for this, like I did here: https://www.eessi.io/docs/blog/2026/02/04/EESSI-at-FOSDEM-26/#eessi-cli-tool

Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/blog/posts/2026/02/easyspack-demo-2.webp
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Binary file added docs/blog/posts/2026/02/easyspack-demo-3.webp
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.