Stop setting spack-packages builtin repo ref in shared environment - #195
Conversation
|
I'd like your opinion and your review. |
tdrwenski
left a comment
There was a problem hiding this comment.
It definitely seems easier for the teams to test spack package updates with this change-- one update in one place and one repo. I don't see any downsides other than some projects might get a bit out of sync with what they are testing, but I'm sure you can keep an eye on that.
I think it's a good idea!
|
FWIW, RAJA Suite projects would resync when we do a coordinated release. |
|
I like this! |
|
@adrienbernede @rhornung67 We will need to update the RAJA spack packages for a camp update and for the RAJA release. Do we want to change to this new approach now or wait until after the RAJA suite release? |
|
@smithsg84 this is precisely the type of use case with will help with. I'm going to merge now and update the RAJA PR so that it's ready for merge as well. |
The RAJA team has been having a hard time trying to test changes in projects approaching a release deadline. The problem is that with spack-packages ref pinned in radiuss-spack-configs, the process to change a package is cumbersome: push a PR in spack-packages, then open a PR in radiuss-spack-configs, and point your project at radiuss-spack-config branch. Each change to the packages requiring the update of radiuss-spack-configs.
So... I changed my mind and suggest we give up enforcing the spack-packages reference in radiuss-spack-configs to allow developers to maintain the spack-packages more responsively.
This PR just remove the reference from the shared environments.
Each project will have to set the spack-packages reference in their .uberenv_config.json. (I have the corresponding PRs ready).
Note: This is how Smith and Axom set their spack-packages reference
Related PRs: