Use spack versions for all packages

[aidanheerdegen]

The guidelines now stipulate full (spack) versions should be used for all packages in a released model:

https://github.com/ACCESS-NRI/dev-docs/wiki/Spack#versioning-working-practice

This is currently not the case for a number of packages:

  packages:
    mom5:
      require:
        - '@git.2025.05.000=access-esm1.6'
    cice5:
      require:
        - '@git.access-esm1.6-2025.11.001=access-esm1.6'
    um7:
      require:
        - '@git.2025.12.000=access-esm1.6'
    gcom4:
      require:
        - '@git.2025.08.000=access-esm1.5'
    access-fms:
      require:
        - '@git.mom5-2025.08.000=mom5'

Can the relevant people let me know what spack version should be used?

mom5, access-fms: @dougiesquire
um7, gcom4: @penguian
cice5: @anton-seaice

If there is no version available one will have to be added to the relevant spack package.

[aidanheerdegen]

Might be a good opportunity to also address #117

[anton-seaice]

cice5 version is imminent - just needs ACCESS-NRI/cice5#68 finished

[dougiesquire]

The MOM5 and FMS SPRs require work to allow us to do this. Do we have any recommendations on how to do Spack versioning when there are multiple source code branches?

[aidanheerdegen]

The MOM5 and FMS SPRs require work to allow us to do this. Do we have any recommendations on how to do Spack versioning when there are multiple source code branches?

Don't have multiple source code branches. And I'm only slightly joking. It's a maintenance nightmare anyway.

If we need to for legacy purposes I'd be fine with creating a legacy spack package for this purpose and shove the horrible old stuff there so it doesn't stop us moving forward.

[dougiesquire]

Ta. As we discussed in person, the MOM5 access-esm1.5 branch is the main issue and that fits squarely in your second option

[aidanheerdegen]

Any objections to creating a spack package to hide away the legacy horror @harshula? I think it has to be in it's own package namespace (e.g. mom5-esm1.5/package.py), but happy to be told otherwise.

[anton-seaice]

My main objection is breaking existing environments, I guess we can wear that (esm1.5 is probably not seeing much development)

Here is the discussion from last time:

ACCESS-NRI/access-spack-packages#331 (comment)

[dougiesquire]

Wow, I have no recollection of that discussion...

[aidanheerdegen]

My main objection is breaking existing environments, I guess we can wear that (esm1.5 is probably not seeing much development)

Specifically access-esm1.5/spack.yaml?

[anton-seaice]

My main objection is breaking existing environments, I guess we can wear that (esm1.5 is probably not seeing much development)

Specifically access-esm1.5/spack.yaml?

Yeah - users clones/ copies/ hacks of that. The actual deployed one we can easily manage the change of (change the spack-packages tag in the same commit as changing the deployment recipe)

[dougiesquire]

This does feel like a low risk for esm1.5. And if/when it does happen, hopefully the user complains and get given the easy fix.

It certainly wouldn't be the first, nor probably last, change to spack packages that isn't backwards compatible...

[harshula]

@dougiesquire :

The MOM5 and FMS SPRs require work to allow us to do this. Do we have any recommendations on how to do Spack versioning when there are multiple source code branches?

@aidanheerdegen :

Any objections to creating a spack package to hide away the legacy horror

That's probably not a general solution to the question. Do you also want to split access-fms into two SPRs? IIRC, @anton-seaice added the branch name as a prefix to the calver for the non main/master branch versions. Also, we have to be mindful that sorting order is intuitive.

[harshula]

Can we wait till after the Spack v1 migration before we make any dramatic changes to SPRs such as using a base class for the common code?

[harshula]

I asked Greg: "We want to change the version() names in https://github.com/ACCESS-NRI/access-spack-packages/blob/main/packages/access-fms/package.py to be Calendar based. However, the source code comes from two different branches. Hence the version name needs to convey when the version is not from the main/master branch. Has the Spack project needed to deal with something like this in the past?"
Greg Answered: "We've typically used suffixes for this sort of thing in the past".