Add warning for spack-packages version compatibility

[aidanheerdegen]

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

[github-actions]

PR Preview
🚀 Preview of PR head commit 4b54fe5 deployed to https://docs.access-hive.org.au/pr-previews/1064
2026-01-20 17:22 AEDT
Preview generated through the Deploy to GitHub Pages workflow run 21161603766.

[aidanheerdegen]

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]

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?

[aidanheerdegen]

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.

[anton-seaice]

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]

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]

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]

Modify and build an ACCESS model's source code

I think this content is most relevant for this page

[aidanheerdegen]

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]

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]

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]

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

[atteggiani]

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]

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]

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]

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]

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 ?