Skip to content

Conversation

@climbfuji
Copy link
Collaborator

@climbfuji climbfuji commented Aug 14, 2025

Description

This PR updates the spack submodule to version 1.0.1 with a few extra commits (see JCSDA/spack#563). The two most important changes are the separation of the spack packages (builtin repo) into its own repository https://github.com/spack/spack-packages, and that compilers are now "nodes" (regular dependencies with a few extra attributes). Please refer to the updated spack documentation and release pages for more details, I cannot cover this here.

The separation of the repository is handled as follows: Our fork of the spack-packages repo https://github.com/jcsda/spack-packages is cloned as a submodule into repos/builtin (and spack is modified to find it there). The spack-stack repo lives under repos/spack_stack as part of the spack-stack GitHub repository. The spack_stack packages were migrated to the new API.

The handling of compilers as nodes means that compilers.yaml no longer exists; instead, compilers are configured under their new names in packages.yaml. The GitHub CI runs on the self-hosted runner illustrate how to do this for a new site config.

The spack-generated modules differ slightly from beforehand:

  • For lmod, modules for packages that do not depend on a compiler are now in modulefiles/Core
  • For tcl/ modules for packages are now in modulefiles/none/none and modulefiles/mpi-name/mpi-version/none/none
  • The module hierarchy names use the new compiler names instead of the legacy names (see spack.aliases)

The compiler changes and the associated updates to the spack engine provided an opportunity to update and simplify the spack stack setup-meta-modules extension significantly. With this, the 7-digit hash for the mpi module names in lmod are removed, and there is no longer a stack-python module. The spack python module is loaded as part of the module dependencies. We still have stack-compiler and stack-mpi.

This PR updates only the Ubuntu self-hosted runner and a few selected site configs (see below, systems affected). I would like to merge this PR without waiting for all other site configs and container builds being updated to make this more manageable. We should create an issue to document that spack-stack develop will be broken for the sites that are not yet updated.

Similarly, only selected templates were updated, all others moved to configs/templates_NOT_YET_CONVERTED_TO_SPACK_v1.

In configs/common, the following compiler packages.yaml are updated: clang, gcc, oneapi. I suggest removing aocc, apple-clang, intel if nobody else is willing to fix them in a follow-up PR.

Site config updates: I encourage spack-stack developers to use the tier1 atlantis or tier2 bounty/blackpearl site configs as blueprints for updating your site configs. Specifically, note one important change for the --compiler= argument for spack stack create env:

spack stack create env --name=ne-oneapi-2025.1.0 --site=blackpearl --template=neptune-dev --compiler=oneapi-2025.1.0 2>&1 | tee log.create.ne-oneapi-2025.1.0.001

if the site contains configs/sites/tierX/sitename/packages_oneapi-2025.1.0.yaml. If the site contains configs/sites/tierX/sitename/packages_oneapi.yaml instead (the versioned and non-versioned files are mutually exclusive), then the command is

spack stack create env --name=ne-oneapi-2025.1.0 --site=blackpearl --template=neptune-dev --compiler=oneapi 2>&1 | tee log.create.ne-oneapi-2025.1.0.001

This is to support multiple versions of the same compiler for a given site. (Side note: Because filter_compilers is no longer needed, it is removed.) Note that spack stack create env will not fail if the file packages_compiler.yaml or packages_compiler-version.yaml doesn't exist - it will print a big and fat warning, though.

MISSING DOCUMENTATION UPDATES - REFER TO A FOLLOW UP PR BY SOMEONE ELSE

Dependencies

Once this PR is merged, we should make an effort to compare our spack-stack-dev branch of spack-packages with the corresponding commit/release of the authoritative repo and quickly send all our changes upstream one by one - we will need to share this work

Issues addressed

Closes #1714
Closes #1731
Closes #1689
Closes #1604
Closes #1274

Applications affected

All

Update and tested templates as part of this PR (all other templates moved to configs/templates_NOT_YET_CONVERTED_TO_SPACK_v1/

  • cylc-dev
  • empty
  • neptune-dev
  • neptune-ops
  • skylab-dev
  • unified-dev note: jedi-tools-env and ai-env removed/commented out; we should create a separate ai-dev template and leave jedi-tools-env in the skylab-dev template only

Systems affected

All

Updated and tested as part of this PR (all other site configs moved to configs/sites__NOT_YET_CONVERTED_TO_SPACK_v1/{tier1,2}/:

  • tier1/atlantis
  • tier1/navy-aws
  • tier2/blackpearl
  • tier2/bounty

Testing

  • CI: Note whether the automatic tests (GitHub actions tests that run automatically for every commit) pass or not
    • GitHub actions CI tests pass
    • GitHub actions CI tests do not pass (provide explanation)
    • GitHub actions CI tests skipped (provide explanation if necessary)
  • New tests added: List and describe any new tests added to GitHub actions
    • ...
  • Additional testing: Add information on any additional tests conducted
    • ...

Checklist

  • This PR addresses one issue/problem/enhancement or has a very good reason for not doing so.
  • These changes have been tested on a number of the affected systems and applications.
  • All dependency PRs/issues have been resolved, and this PR can be merged.
  • All necessary updates to the documentation on readthedocs are included in this PR
    • For site config updates, check in particular doc/source/PreConfiguredSites.rst and doc/source/MaintainersSection.rst
  • All necessary updates to the spack-stack wiki will be made when this PR is merged

Documentation and wiki updates deferred to follow-up PRs

climbfuji added 30 commits July 22, 2025 09:03
…pack-stack to new api version 2 under repos/spack_stack
…pack_stack/spack_repo/spack_stack/packages/neptune_env/package.py, repos/spack_stack/spack_repo/spack_stack/packages/neptune_python_env/package.py
…/spack_repo/spack_stack/packages/neptune_python_env/package.py
@AlexanderRichert-NOAA
Copy link
Collaborator

FWIW, changing flag_values = compiler["compiler"]["flags"][flag_name] to flag_values = compiler.extra_attributes["flags"][flag_name] allowed me to generate the metamodules (including correctly populating the various flags).

@climbfuji
Copy link
Collaborator Author

FWIW, changing flag_values = compiler["compiler"]["flags"][flag_name] to flag_values = compiler.extra_attributes["flags"][flag_name] allowed me to generate the metamodules (including correctly populating the various flags).

See b39a46b please

@climbfuji
Copy link
Collaborator Author

Ping - just a quick check if this PR is ok to go into the new staging branch [JCSDA:feature/update_to_spack_v1](https://github.com/JCSDA/spack-stack/tree/feature/update_to_spack_v1)?

@AlexanderRichert-NOAA
Copy link
Collaborator

Fine by me

Copy link
Collaborator

@mathomp4 mathomp4 left a comment

Choose a reason for hiding this comment

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

I'm still having weird NAS issues, but for now, trust in Dom.

@climbfuji climbfuji enabled auto-merge (squash) September 25, 2025 17:14
@climbfuji climbfuji merged commit dda49c1 into JCSDA:feature/update_to_spack_v1 Sep 25, 2025
7 checks passed
@github-project-automation github-project-automation bot moved this from In Progress to Done in spack-stack-2.0.x (2025 Q4) Sep 25, 2025
@eap
Copy link
Collaborator

eap commented Sep 25, 2025

as of yesterday I've got this building, I'm still working to get jedi bundle to build and have leftover questions but I can bring that up on Tuesday. Thanks for this @climbfuji

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

5 participants