Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inject Values for spack.modules.default.tcl.projections #169

Open
CodeGat opened this issue Nov 15, 2024 · 3 comments
Open

Inject Values for spack.modules.default.tcl.projections #169

CodeGat opened this issue Nov 15, 2024 · 3 comments
Labels
priority:high type:enhancement Improvements to existing features

Comments

@CodeGat
Copy link
Member

CodeGat commented Nov 15, 2024

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 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.
@CodeGat CodeGat added priority:high type:enhancement Improvements to existing features labels Nov 15, 2024
@CodeGat CodeGat self-assigned this Nov 15, 2024
@harshula
Copy link
Contributor

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?

@CodeGat
Copy link
Member Author

CodeGat commented Nov 18, 2024

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).

@CodeGat
Copy link
Member Author

CodeGat commented Nov 20, 2024

Parking this until we have a rigorous shadow organisation test environment - it'll be a big change

@CodeGat CodeGat removed their assignment Nov 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority:high type:enhancement Improvements to existing features
Projects
None yet
Development

No branches or pull requests

2 participants