Add 2nd Blog post on Spack+EESSI, + corrections to 1st #675

boegel · 2026-02-05T19:17:09Z

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...

oh, I didn't know you could copy-past from that! I'll look into it...

boegel · 2026-02-05T19:19:58Z

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

ocaisa · 2026-02-05T15:17:19Z

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.

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... 😅)

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

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.

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

I see, practically we cannot have "Spack" in the name.
I like some of Todd's ideas ("Spork" is great :D), but they are already taken by other projects on PyPI.
Some variation that could work:

eSpork (or ESpork)

EESSI-Spork

EasyBridge

What do you guys think? :)
BTW, eSpork already has a mascotte 🐷😆

This may be a stretch but spood is not taken on PyPI. It’s (affectionate) slang for spider 🕷️ .

Since this thing spiders EESSI modules and connects the web of dependencies to spack, I think it works. Also makes for a good mascot. Thoughts?

I would avoid using EESSI and EasyBuild as well, since we have plans to make those HPSF projects as well, and hence Linux Foundation will have trademark on those too...

spood has sorta a nice ring to it, but also seems like a word that may easily mean something totally different in some language.

That said, @lorisercole's repo isn't really about a standalone tool, I think, but fine, it still needs some name, might as well go with spood...

Gemini seems to think it’s safe:

Verdict
It is not an offensive slur in any major language.
The biggest risk is that Dutch speakers might chuckle because it sounds like "Speed" or "Squirted." If you want to lean into the "Speed/Haste" meaning, it’s actually a happy accident!

"spoed" in Dutch means "haste" or "emergency room", so it's not entirely wrong, but it's a stretch even for Dutch-speaking people

boegel · 2026-02-05T18:48:29Z

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

-Original file line number
+Diff line change
@@ Expand Up @@
     ### 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 @@
     ![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 @@
     ![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!

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add 2nd Blog post on Spack+EESSI, + corrections to 1st #675

Uh oh!

Diff view

Diff view

There are no files selected for viewing

boegel Feb 5, 2026

Uh oh!

lorisercole Feb 6, 2026

Uh oh!

Uh oh!

boegel Feb 5, 2026

Uh oh!

ocaisa Feb 5, 2026

Uh oh!

lorisercole Feb 5, 2026

Uh oh!

ocaisa Feb 5, 2026

Uh oh!

tgamblin Feb 5, 2026

Uh oh!

boegel Feb 5, 2026

Uh oh!

lorisercole Feb 6, 2026 •

edited

Loading

Uh oh!

tgamblin Feb 6, 2026 •

edited

Loading

Uh oh!

boegel Feb 6, 2026

Uh oh!

tgamblin Feb 6, 2026

Uh oh!

boegel Feb 7, 2026

Uh oh!

boegel Feb 5, 2026

Uh oh!

-Original file line number
+Diff line change
@@ -0,0 +1,233 @@
+    ---
+    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 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 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](../../../../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).
+    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 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](../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 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 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.
+    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 – External packages for EESSI software layer
+    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).
+    ```yaml
+    # Example of packages.yaml file for EESSI software stack without compat-layer packages (to be added by detection tool)
+    # EESSI detected microarchitecture: haswell
+    packages:
+      gcc:
+        externals:
+        - spec: gcc@13.2.0 languages:='c,c++,fortran' target=haswell
+          prefix: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/GCCcore/13.2.0
+          dependencies: []
+          extra_attributes:
+            compilers:
+              c: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/GCCcore/13.2.0/bin/gcc
+              cxx: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/GCCcore/13.2.0/bin/g++
+              fortran: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/GCCcore/13.2.0/bin/gfortran
+      gmake:
+        externals:
+        - spec: gmake@4.4.1 target=haswell
+          prefix: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/make/4.4.1-GCCcore-13.2.0
+          dependencies:
+          - spec: gcc@13.2.0 target=haswell
+      openblas:
+        externals:
+        - spec: openblas@0.3.24~ilp64 threads=openmp target=haswell
+          prefix: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/OpenBLAS/0.3.24-GCC-13.2.0
+          dependencies:
+          - spec: gcc@13.2.0 target=haswell
+      fftw:
+        externals:
+        - spec: fftw@3.3.10~mpi+openmp+shared precision=float,double,long_double,quad target=haswell
+          prefix: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/FFTW/3.3.10-GCC-13.2.0
+          dependencies:
+          - spec: gcc@13.2.0 target=haswell
+      curl:
+        externals:
+        - spec: curl@8.3.0+nghttp2 target=haswell
+          prefix: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/cURL/8.3.0-GCCcore-13.2.0
+          dependencies:
+          - spec: gcc@13.2.0 target=haswell
+          - spec: zlib@1.2.13  # compat
+            deptypes:
+            - link
+          - spec: openssl@1.1.1w  # compat
+            deptypes:
+            - build
+            - link
+      libarchive:
+        externals:
+        - spec: libarchive@3.7.2 target=haswell
+          prefix: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/libarchive/3.7.2-GCCcore-13.2.0
+          dependencies:
+          - spec: gcc@13.2.0 target=haswell
+      cmake:
+        externals:
+        - spec: cmake@3.31.8 target=haswell
+          prefix: /cvmfs/software.eessi.io/versions/2023.06/software/linux/x86_64/intel/haswell/software/CMake/3.27.6-GCCcore-13.2.0
+          dependencies:
+          - spec: gcc@13.2.0 target=haswell
+          - spec: curl@8.3.0 target=haswell
+            deptypes:
+            - build
+            - link
+          - spec: ncurses@6.4.20230401  # compat
+            deptypes:
+            - build
+            - link
+          - spec: zlib@1.2.13  # compat
+            deptypes:
+            - build
+            - link
+          - spec: libarchive@3.7.2 target=haswell
+            deptypes:
+            - build
+            - link
+          - spec: bzip2@1.0.8  # compat
+            deptypes:
+            - link
+          - spec: openssl@1.1.1w  # compat
+            deptypes:
+            - build
+            - link
+    ```
+    *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*, 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).
+    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 compatibility layer
+    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)
+    ### 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)
+    ### 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).
+    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]({{ config.extra.slack_invite_url }}), as well as our weekly [EESSI Happy Hour sessions](https://www.eessi.io/docs/training-events/happy-hours-sessions/), and share your experiences and suggestions!
+    ### Acknowledgements
+    This work was made possible thanks to the collaboration with the Spack development team, in particular [Todd Gamblin](https://github.com/tgamblin) and [Massimiliano Culpo](https://github.com/alalazo), as well as EESSI team members [Kenneth Hoste](https://github.com/boegel) and [Alan O'Cais](https://github.com/ocaisa).

Add 2nd Blog post on Spack+EESSI, + corrections to 1st #675

Are you sure you want to change the base?

Uh oh!

Add 2nd Blog post on Spack+EESSI, + corrections to 1st #675

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lorisercole Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tgamblin Feb 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lorisercole Feb 6, 2026 •

edited

Loading

tgamblin Feb 6, 2026 •

edited

Loading