spack develop with AM3

[Whyborn]

The standard spack develop workflow won't work for AM3 for anyone modifying the UM components (including UM itself). This is because both the base fetcher and the bespoke _dynamic_resource refer explicitly to the remote repository in the UM build system. A good long term plan would be to convert each of the components into their own spack packages, and then fetch them based on where Spack think they should come from. This would allow spack develop workflows to behave as expected, and it means the component refs will be specified in the standard way rather than the <component>_ref variants used currently. (@Jordan-SRH this might be relevant to you soon?)

[harshula]

Hi @Whyborn , What was the exact spack develop command that you ran?

[Whyborn]

Also important to note that while the AM3 spack packages currently allows refs to be branches, and it sounds nice in theory for the spack develop workflow, changes on that branch do not get pulled automatically when calling spack install, as Spack sees that the model spec (which includes the component refs) is unchanged. It is possible to dive into the UM and modify the code in the resources repository

[Whyborn]

Ah for AM3, I think I just used

spack develop um

and then modified the spec to include the desired variants under the develop section in the spack.yaml

[harshula]

Hi @Whyborn , Can you please try spack develop um@<version> <variant1> <variant2> ... <variantN> with no pre-existing source directories? I would expect spack develop to extract the source code the same way a spack install would as long as spack develop is provided all the required information.

e.g spack develop um@13.1 model="vn13p1-am" jules_ref="2025.08.0" um_ref="2025.08.0"

[Whyborn]

Unfortunately not- it doesn't pull the resources until the patch stage, which doesn't occur when calling spack develop. It fetches the um repository, but doesn't pull in jules, ukca, shumlib etc.

[harshula]

Thanks @Whyborn for testing. I'll mention this issue to Spack upstream.

[harshula]

Hi @Whyborn , Do you have a workaround at the moment? If so, which commands do you run?

[Whyborn]

For the UM components, the workaround I'm using it to call spack install once, which downloads the resources and places them in resources in the target UM directory (either cloned via spack develop or manually cloned and pointed to by spack develop). I can then modify that source code that lives in the resources directory.

[Whyborn]

The spack patch um@13.1 behaved as expected- all the desired components were cloned into um/resources, and they are valid Git repositories with links to the respective remotes.