Spack v1 Cheat Sheet

Technical spack
1

Spack v1 Cheat Sheet

Can Spack find existing system installed compilers?

  • Yes, run spack compiler find

Can Spack simulate spack install <spec> concretization step?

  • spack solve <spec>

How do I manage Spack repositories that contain Spack Package Recipes?

  • spack repo <command>
  • spack repo --help

How do I edit a Spack Package Recipe in a Spack managed repository?

  • spack edit <SPR-name>

What happened to ACCESS-NRI’s spack-packages directory?

  • ACCESS-NRI renamed our spack-packages repository to access-spack-packages. Unlike Spack v0.22, Spack v1.1 manages the ACCESS-NRI repository for the end user. Run spack repo list to see all the repositories managed by Spack.

Can git be used on the Spack managed repositories?

  • Yes. e.g. git -C $spack/../package_repos/3t2klr5 log

Can externals be added to a spack.yaml environment file?

  • Yes!

Why is Spack using a mixture of underscore (“_”) and hypen (“-”) in the names of directories and files?

How to modify an existing repo in repos.yaml from a higher precedence scope:

[root@5ca9101ef997 site]# spack config blame repos
---                                      repos:
/opt/spack/etc/spack/site/repos.yaml:3     access_spack_packages:
/opt/spack/etc/spack/site/repos.yaml:4       git: https://github.com/ACCESS-NRI/access-spack-packages.git
/opt/spack/etc/spack/site/repos.yaml:5       branch: api-v2
/opt/spack/etc/spack/site/repos.yaml:6       destination: $spack/../access-spack-packages
/opt/spack/etc/spack/site/repos.yaml:7     builtin:
/opt/spack/etc/spack/site/repos.yaml:8       git: https://github.com/spack/spack-packages.git
/opt/spack/etc/spack/site/repos.yaml:10      commit: 2f02a99ec9dfd5dceb9bd91abc392edabd9ba963

[root@5ca9101ef997 site]# spack repo add --scope=user --name builtin https://github.com/spack/spack-packages.git 
==> Added repo to config with name 'builtin'.

[root@5ca9101ef997 site]# spack repo update --scope=user --commit 383e969358c951abe17623696083e6f862c4488e builtin
==> builtin: Already up to date.

[root@5ca9101ef997 site]# spack config blame repos
---                                     repos:
/root/.spack/repos.yaml:2                 builtin:
/root/.spack/repos.yaml:3                   git: https://github.com/spack/spack-packages.git
/root/.spack/repos.yaml:4                   commit: 383e969358c951abe17623696083e6f862c4488e
/opt/spack/etc/spack/site/repos.yaml:3    access_spack_packages:
/opt/spack/etc/spack/site/repos.yaml:4      git: https://github.com/ACCESS-NRI/access-spack-packages.git
/opt/spack/etc/spack/site/repos.yaml:5      branch: api-v2
/opt/spack/etc/spack/site/repos.yaml:6      destination: $spack/../access-spack-packages

The Spack concretizer chose the wrong package!

The Spack v1 concretizer is opinionated! The Spack Package Recipe contained:

    depends_on("c", type="build")
    depends_on("fortran", type="build")
    depends_on("mpi")

    build_system("cmake", "makefile", default="cmake")

However, the Spack concretizer chose makefile even though cmake was the default:

 -   access-mocsy@stable build_system=makefile commit=b136e1a70b9959333b0258b07863ebb05c4ff5f7 platform=linux os=rocky8 target=x86_64 %c,cxx,fortran=gcc@13.2.0

Spack upstream found that this decision was made because the cmake version we had required was deprecated, even though using deprecated versions was enabled by setting deprecated: True was set in config.yaml.

Running spack solve can help with debugging:

--- cmake.txt	2026-03-13 11:03:18.643378274 +1100
+++ makefile.txt	2026-03-13 11:02:53.490965502 +1100
@@ -1,13 +1,12 @@
-[test] [root@e5843698fd94 test]# spack solve access-mocsy build_system=cmake
+[test] [root@e5843698fd94 opt]# spack solve access-mocsy build_system=makefile
 ==> SOLVING SPEC:
-  access-mocsy build_system=cmake
-==> Warning: using "cmake@3.31.6" which is a deprecated version
+  access-mocsy build_system=makefile
 ==> Warning: Unable to resolve the git commit for access-mocsy. An installation of this binary won't have complete binary provenance.
 ==> Best of 5 considered solutions.
 
   Priority  Value  Criterion
          1      0  requirement weight                                   
-         2      1  deprecated versions used                             
+         2      0  deprecated versions used                             
          3      0  version badness (roots)                              
          4      0  number of non-default variants (roots)               
          5      0  preferred providers for roots