You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The spack.modules.default.tcl.projections section is a section that creates a bit of a headache for users. It adds checks that the version in spack.packages.*.require[0] section is equivalent (some exceptions for @git.-and-=RHS-style versions) to spack.modules.default.tcl.projections.
Unfortunately, this means that users often have to write the same thing twice. For example, changing a version of mom5 means that they must also change the equivalent projection. This trips up people regularly, enough times that I've kind of gone back on my more extreme what-you-see-is-what-you-get stance that we should never have the CI modify the spack.yaml. Even this had been chipped away at earlier anyway - we do sneakily modify the spack.yaml to give Prereleases the familiar MODEL/prX-Y modulefile name that we all know and love.
Implementation Details
Have the CI inject the appropriate projections into the spack.yaml before it is sent off to the deployment targets for install. This should be a fairly simple yq in-place edit based on the values in spack.packages. The modified version is still accessible as a workflow and release artifact.
If a user overrides the projections by setting the spack.modules.default.tcl.projections, let them. Do not inject any of the values.
The text was updated successfully, but these errors were encountered:
Is there a way to make sure the spack.yaml based build-cd deployment has the same moduelfile projections as a git clone of a model deployment repository followed by a Spack-based build?
Hmm, I don't know how that would be possible...the point of this issue was to get rid of the projections section entirely (except for power users, of course).
Background
The
spack.modules.default.tcl.projections
section is a section that creates a bit of a headache for users. It adds checks that the version inspack.packages.*.require[0]
section is equivalent (some exceptions for@git.
-and-=RHS
-style versions) tospack.modules.default.tcl.projections
.Unfortunately, this means that users often have to write the same thing twice. For example, changing a version of
mom5
means that they must also change the equivalent projection. This trips up people regularly, enough times that I've kind of gone back on my more extreme what-you-see-is-what-you-get stance that we should never have the CI modify thespack.yaml
. Even this had been chipped away at earlier anyway - we do sneakily modify thespack.yaml
to give Prereleases the familiarMODEL/prX-Y
modulefile name that we all know and love.Implementation Details
spack.yaml
before it is sent off to the deployment targets for install. This should be a fairly simpleyq
in-place edit based on the values inspack.packages
. The modified version is still accessible as a workflow and release artifact.spack.modules.default.tcl.projections
, let them. Do not inject any of the values.The text was updated successfully, but these errors were encountered: