Add warning for spack-packages version compatibility by aidanheerdegen · Pull Request #1064 · ACCESS-NRI/ACCESS-Hive-Docs

aidanheerdegen · 2025-11-11T05:45:59Z

ACCESS-Hive Docs

Description

Added a warning about version compatibility for spack-packages.

Fixes #987

Type of change

Please delete options that are not relevant.

Bug fix (non-breaking change which fixes an issue, e.g. dead links)
New link / content

Checklist:

The new content is accessible and located in the appropriate section
My changes do not break navigation and do not generate new warnings
I have checked that the links are valid and point to the intended content
I have checked my code/text and corrected any misspellings

Added a warning about version compatibility for spack-packages.

aidanheerdegen · 2025-11-11T05:49:50Z

I could put a similar warning in the Create Prereleases and Releases for an ACCESS Model page.

Necessary?

atteggiani

Thanks @aidanheerdegen for this PR.

There's a minor rendering issue I left a suggestion for.
In the same comment there is another point that might be relevant.

atteggiani · 2025-11-11T06:22:59Z

docs/models/build_a_model/create_a_prerelease.md

+    !!! warning
+        It is important that the version of [`access-nri/spack-packages`](https://github.com/ACCESS-NRI/spack-packages) is compatible with the environment. 
+        If there are concretization errors try checking this.
+


Indentation problem.

Suggested change

!!! warning

It is important that the version of [`access-nri/spack-packages`](https://github.com/ACCESS-NRI/spack-packages) is compatible with the environment.

If there are concretization errors try checking this.

!!! warning

It is important that the version of [`access-nri/spack-packages`](https://github.com/ACCESS-NRI/spack-packages) is compatible with the environment. If there are concretization errors try checking this.

What does "compatible" mean in this case? How would a user check that the spack-packages version is compatible with the spack environment?

Instead of saying "... try checking this", could we quickly describe how a user would check for such compatibility?

What does "compatible" mean in this case? How would a user check that the spack-packages version is compatible with the spack environment?

I was deliberately vague because there is no easy answer to your question. They might need to use the most recent version because then they get all the most recent spack package changes.

Or they might need to use an older version, because they need to remain consistent with the spack packages at an earlier time. There can be inter-dependency between the packages, where changes have to be made in sync so they are consistent.

Perhaps this is the right time to ask @anton-seaice if he had any specific use-cases in mind.

Instead of saying "... try checking this", could we quickly describe how a user would check for such compatibility?

I think the docs already cover where the spack packages version is set. Would it be sufficient to refer to that with a "see above" type direction? Other than that, to know what the "correct" version is depends on what they're trying to do. If it is to be consistent with a released version, then they should use what that environment did. If they're developing something new, then who knows? It would require some careful inspection of package recipes.

Perhaps this is the right time to ask @anton-seaice if he had any specific use-cases in mind.

The main thing folks get stuck on is:

they clone spack-packages latest from main

checkout spack.yaml environment file from a deployment repo

and then find it doesn't concretise/build, becuase spack-packages has had a breaking change since the model was last deployed

Possibly if we are very careful with version dependencies going forward this won't continue to be a problem

atteggiani · 2025-11-11T06:27:50Z

I could put a similar warning in the Create Prereleases and Releases for an ACCESS Model page.

I believe you added the warning in the "Create Prereleases and Releases for an ACCESS Model" page you mention.
Did you mean to add the warning in the Modify and build an ACCESS model's source code or Set up Spack for building ACCESS models pages?

aidanheerdegen · 2025-11-11T22:41:32Z

I could put a similar warning in the Create Prereleases and Releases for an ACCESS Model page.

I believe you added the warning in the "Create Prereleases and Releases for an ACCESS Model" page you mention. Did you mean to add the warning in the Modify and build an ACCESS model's source code or Set up Spack for building ACCESS models pages?

Almost certainly! :)

Thanks for translating my confusing comment.

anton-seaice · 2025-11-12T00:19:41Z

Modify and build an ACCESS model's source code

I think this content is most relevant for this page

aidanheerdegen · 2025-11-12T02:42:27Z

I think this content is most relevant for this page

Except that page isn't where the instructions to clone spack-packages is located. That is in https://docs.access-hive.org.au/pr-previews/1064/getting_started/spack/

anton-seaice · 2025-11-12T03:10:25Z

Except that page isn't where the instructions to clone spack-packages is located. That is in https://docs.access-hive.org.au/pr-previews/1064/getting_started/spack/

Are you suggesting changing the docs to say "clone spack-packages from a specific tag" ?

Building from source is when the problem comes up

aidanheerdegen · 2025-11-13T02:56:51Z

Are you suggesting changing the docs to say "clone spack-packages from a specific tag" ?

Building from source is when the problem comes up

Yeah. but I couldn't see a good place to put it. I took another look and decided to try putting it in the part where the concretization is done in this commit: 4b54fe5

Can you take a look and see if that covers the use case you wanted?

harshula · 2025-11-27T08:26:01Z

FYI, This issue may disappear once we move to Spack v1.1 because it allows Spack to mange access-spack-packages directly.

atteggiani · 2025-12-02T00:09:13Z

FYI, This issue may disappear once we move to Spack v1.1 because it allows Spack to mange access-spack-packages directly.

@harshula
Do you think this PR will not be relevant anymore then? Do you suggest closing it (or turning it to draft for now)?

harshula · 2025-12-02T05:42:10Z

Hi @CodeGat , Do you think you'll go down the path of putting access-spack-packages in the spack,yaml under repos: and the destination is injected?

CodeGat · 2025-12-02T20:43:19Z

I think not. Seems there would be a bit of double up with spack-config cloning that repository when spack bootstraps, and when the environment is created with another spack.repos key.
I think we should keep it as is - a field in the versions.json

atteggiani · 2025-12-08T23:55:04Z

I think not. Seems there would be a bit of double up with spack-config cloning that repository when spack bootstraps, and when the environment is created with another spack.repos key. I think we should keep it as is - a field in the versions.json

@harshula
Based on my understanding this means this PR will still be relevant right?

anton-seaice

Sorry - review was pending from a month ago !

anton-seaice · 2025-11-13T03:30:56Z

docs/models/build_a_model/build_source_code.md

    spack concretize -f --fresh
    ```

+    The version of [`access-nri/access-spack-packages`](https://github.com/ACCESS-NRI/access-spack-packages) must be compatible with the environment. If there are concretization errors try checking the version you cloned is the same as the version used in the deployment repository.


Suggested change

The version of [`access-nri/access-spack-packages`](https://github.com/ACCESS-NRI/access-spack-packages) must be compatible with the environment. If there are concretization errors try checking the version you cloned is the same as the version used in the deployment repository.

!!! warning

The version of [`access-nri/access-spack-packages`](https://github.com/ACCESS-NRI/access-spack-packages) must be compatible with the environment. If there are concretization errors try checking the version you cloned is the same as the version used in the deployment repository.

Should this be a seperate warning? Its not very clear having two warnings in the same box

Can we be more explicit? How do i check the version ?

heidinett · 2026-02-09T23:38:19Z

@aidanheerdegen have you got any update on this?

aidanheerdegen · 2026-02-26T03:16:57Z

access-spack-packages is now cloned and controlled by spack, so I'm not sure this is still relevant.

Any opinions @anton-seaice @harshula ?

anton-seaice · 2026-02-26T03:22:30Z

That doesn't address the original problem though. There will still be cases where cloning the latest spack and trying to build an environment doesn't work because some aspect of spack or spack-packages has changed between the time that environment was deployed and the latest spack.

aidanheerdegen · 2026-03-02T00:58:03Z

There will still be cases where cloning the latest spack and trying to build an environment doesn't work because some aspect of spack or spack-packages has changed between the time that environment was deployed and the latest spack.

I'm having trouble knowing what to put in this PR because I have not encountered the problem you describe @anton-seaice. I don't know how to proceed at this point.

If you still feel strongly about this @anton-seaice I suggest you either take over this PR and add your own changes, or make your own PR and I'll close this one.

anton-seaice · 2026-03-02T01:35:49Z

I guess we could ignore this and assist people as needed - e.g. https://forum.access-hive.org.au/t/building-access-om3/4792

I'm not sure i understand how the pieces fit together well enough to be sure. It looks like:

spack checks out some version of the access-nri packages to this folder: package_repos/3t2klr5/spack_repo/access/nri. Presumably the latest from api-v2 branch ?
And then build-CD updates it to the configured version ?

So the instructions should say to use the version configured in the deployment repository non ?

harshula · 2026-03-03T00:55:43Z

Hi @anton-seaice ,

spack checks out some version of the access-nri packages to this folder: package_repos/3t2klr5/spack_repo/access/nri

That behaviour has changed since PR ACCESS-NRI/spack-config#103 .

anton-seaice · 2026-03-03T22:00:59Z

Restarted this with #1157

Add warning for spack-packages version compatibility

f91ceb6

Added a warning about version compatibility for spack-packages.

aidanheerdegen requested a review from a team as a code owner November 11, 2025 05:46

aidanheerdegen requested review from anton-seaice and harshula November 11, 2025 06:07

atteggiani requested changes Nov 11, 2025

View reviewed changes

Add access-spack-packages warning to build source code page

4b54fe5

atteggiani force-pushed the development branch from 254ca6a to 963790e Compare November 27, 2025 06:11

anton-seaice reviewed Dec 9, 2025

View reviewed changes

anton-seaice mentioned this pull request Mar 3, 2026

Note on setting spack packages version #1157

Merged

anton-seaice closed this Mar 3, 2026

anton-seaice deleted the 987-spack-packages-version-warning branch March 3, 2026 22:01

Conversation

aidanheerdegen commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

ACCESS-Hive Docs

Description

Type of change

Checklist:

Uh oh!

aidanheerdegen commented Nov 11, 2025

Uh oh!

atteggiani left a comment

Choose a reason for hiding this comment

Uh oh!

atteggiani Nov 11, 2025 • 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!

aidanheerdegen Nov 11, 2025

Choose a reason for hiding this comment

Uh oh!

anton-seaice Nov 12, 2025

Choose a reason for hiding this comment

Uh oh!

atteggiani commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

aidanheerdegen commented Nov 11, 2025

Uh oh!

anton-seaice commented Nov 12, 2025

Uh oh!

aidanheerdegen commented Nov 12, 2025

Uh oh!

anton-seaice commented Nov 12, 2025

Uh oh!

aidanheerdegen commented Nov 13, 2025

Uh oh!

harshula commented Nov 27, 2025

Uh oh!

atteggiani commented Dec 2, 2025

Uh oh!

harshula commented Dec 2, 2025

Uh oh!

CodeGat commented Dec 2, 2025

Uh oh!

atteggiani commented Dec 8, 2025

Uh oh!

anton-seaice left a comment

Choose a reason for hiding this comment

Uh oh!

anton-seaice Nov 13, 2025

Choose a reason for hiding this comment

Uh oh!

heidinett commented Feb 9, 2026

Uh oh!

aidanheerdegen commented Feb 26, 2026

Uh oh!

anton-seaice commented Feb 26, 2026

Uh oh!

aidanheerdegen commented Mar 2, 2026

Uh oh!

anton-seaice commented Mar 2, 2026

Uh oh!

harshula commented Mar 3, 2026

Uh oh!

anton-seaice commented Mar 3, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

aidanheerdegen commented Nov 11, 2025 •

edited

Loading

atteggiani Nov 11, 2025 •

edited

Loading

atteggiani commented Nov 11, 2025 •

edited

Loading