In preparation for the Spack meeting, please put all your ACCESS-NRI Spack questions here.
Find a Different Way to Get the Git URL of a Package Without Concretizing · Issue #147 · ACCESS-NRI/build-cd · GitHub Regarding getting the git url from a package programmatically.
What’s the best way to add the Spack hash to model component module names but not add the Spack hash to the model module name? e.g How do we avoid access-om2/pr76-29-fgwtotw
but have mom5/git.2024.08.23_2024.08.23-oi2lpoe
?
Ask about feature: sharing a spack instance by carsonwoods · Pull Request #11871 · spack/spack · GitHub
Describe what our users want to do by showing these two examples:
https://access-hive.org.au/getting_started/spack/
https://access-hive.org.au/models/run-a-model/build_a_model/
Ask for advice on better ways to do this.
Is a package’s Spack hash influenced by building inside Vs outside an environment?
What is the best way to reduce the inode usage of a multi-user Spack installation? In particular, what can be shared between users? If this question is too vague, you can describe the current ACCESS-NRI Spack installation, including the three repositories: spack
, spack-config
and spack-packages
.
Can Multi-value variants turn-off the default value?
- Does
@git.BRANCH
interrogate the state of the branch during concretization? I’ve been aware of times that spack has preferred to use an already cached (but older, based on git history) package. I’ve been trying to set up a containerised solution in which an upstream spack contains just a set of compilers that can be used by the downstream containerised spack. So far it hasn’t worked for the compilers (although it does work for the packages). Is this the kind of workflow that is expected in 1.0.0?Fixed it
This works
variant(
"configurations",
values=any_combination_of(*KNOWN_CONF),
)
Which is ok but imperfect. If forces there to be a ‘none’ variant and there is no clear way to prevent there being a ‘none’ option during concretisation. (Adding .prohibit_empty_set()
doesn’t help).
Is there a neater way for complex logic (e.g. one OR another compiler) for depends_on()
calls ?
e.g. depends_on needs to be set in the class definition (so its available during concretise), but this means the configuration gets messy. e.g.:
depends_on("esmf cflags='-fp-model precise' fflags='-fp-model precise'", when="%intel")
depends_on("esmf cflags='-fp-model precise' fflags='-fp-model precise'", when="%oneapi")
or
depends_on("access-cice", when="configurations=CICE6"),
depends_on("access-cice", when="configurations=MOM6-CICE6"),
depends_on("access-cice", when="configurations=MOM6-CICE6-WW3"),
depends_on("access-cice", when="configurations=none")
The following didn’t have the desired outcome:
all:
require:
- '%intel@2021.10.0'
- 'target=x86_64'
- 'fflags="-fp-model strict -check all -check noarg_temp_created -init=snan -init=array -init=huge"'
However, this did:
packages:
cice5:
require:
- '@git.2025.03.001=access-om2'
- 'fflags="-fp-model strict -check all -check noarg_temp_created -init=snan -init=array -init=huge"'
mom5:
require:
- '@git.2025.03.001=access-om2'
- 'fflags="-fp-model strict -check all -check noarg_temp_created -init=snan -init=array -init=huge"'
libaccessom2:
require:
- '@git.2023.10.26=access-om2'
- 'fflags="-fp-model strict -check all -check noarg_temp_created -init=snan -init=array -init=huge"'
oasis3-mct:
require:
- '@git.2025.03.001=access-om2'
- 'fflags="-fp-model strict -check all -check noarg_temp_created -init=snan -init=array -init=huge"'
When using spack develop
, how can the user force a make clean
to start from a pristine source tree that does not contain old/stale intermediate files?
Should we stop using unify: true
and start using unify: false
?
Does Spack have the functional equivalent to apt source <packagename>
?