Making The Root Spec Unremarkable With Reserved spack.definitions #330
Description
After a discussion with @anton-seaice and @harshula...
Important
This would also be a major update to the infrastructure. We are looking to bundle this in with the v8 - spack v1 migration changes so we don't have to update ANOTHER set of MDRs
Background
Currently, in MDRs, the root spec (the first line in the spack.specs section) holds a lot of meaning. It is both the name of the top-level bundle (and hence the name of the top-level modulefile), and the version of the overall deployment.
One of the main drawbacks of having a git version associated with a spec is in the case of Prereleases - since the version is the future tag associated with the deployment, users can't simply grab the manifest from a prerelease and install it into their own instance - as the tag doesn't yet exist! The infra gets around this by stripping the version in Prereleases, but this isn't exactly clean either.
Another drawback is in the case of multiple specs in a manifest. As noted by @anton-seaice, in the case where we may want to deploy multiple specs that differ in dependency variants, we have a speclist like:
- [email protected] ^cice x=A y=B
- access-om2 ^cice x=C y=D
- access-om2 ^cice x=E y=FImplementation Plan
Instead of having these important aspects be part of the speclist directly, we can have them as sort of reserved, dummy definitions, unused by speclists:
spack:
definitions:
- _name: [access-om2]
- _version: [2025.11.000]
specs:
- access-om2
# ...This leaves the speclist clean and more open to modification, allows users to freely copy manifests into their own instances without needing to make modifications, and makes the build-cd more easy to maintain. It also opens the door to other reserved variants appearing in the future.
Pinging @aidanheerdegen and @manodeep too, for fun