config: use prefer_modify: true to adjust edit preferences#51510
Merged
config: use prefer_modify: true to adjust edit preferences#51510
config: use prefer_modify: true to adjust edit preferences#51510Conversation
tgamblin
changed the title
concur: use prefer_modify: true to adjust edit preferencesconfig: use prefer_modify: true to adjust edit preferences
#51162 allows users to specify configuration scopes as configuration, but it also changes the `spack` scope to be the default edit scope. This can be extremely confusing to users, as it causes `spack compiler find`, `spack external find`, `spack config add`, etc. to be written into the spack instance by default instead of into `~/.spack`. `~/.spack` is a better choice if it's configured, as we do not know if the user actually owns the spack instance. It's also what people are used to, and it's going to cause a lot of consternation if we switch this default up on people. This PR introduces a new `prefer_modify: true` option on `include:` that allows the including scope to hand off edit precedence to an included scope. The including scope is still modifiable if specified explicitly by name (e.g., `--scope spack`) but if it is selected by default, we'll edit its `prefer_modify` scope instead. - [x] Add `prefer_modify:` option to `include:` - [x] Make the default `spack` scope specify the user scope as `prefer_modify:`. - [x] Add documentation and update `include:` docs with `versionadded` directives. - [x] make the `user` scope `prefer_modify:` in `$spack/etc/spack/include.yaml` Signed-off-by: Todd Gamblin <[email protected]>
tgamblin
force-pushed
the
config-prefer-modify
branch
from
97c2ffe to
d98563b
Compare
alecbcs
previously approved these changes
Nov 5, 2025
psakievich
reviewed
Nov 5, 2025
psakievich
reviewed
Nov 5, 2025
Contributor
psakievich
left a comment
psakievich
left a comment
There was a problem hiding this comment.
Overall, I think this is the best option for preserving default behavior while still adding the spack scope. I could see a long term use for the new config option, but overall I'm not in love with it. I feel like the option may rot as soon as people realize they don't need to go to such great lengths to avoid the user scope. I would advocate for a minor release in this state to socialize the intended change then set it to false.
becker33
previously approved these changes
Nov 5, 2025
Signed-off-by: Todd Gamblin <[email protected]>
becker33
approved these changes
Nov 6, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
#51162 allows users to specify configuration scopes as configuration, but it also changes the
spackscope to be the default edit scope. This can be extremely confusing to users, as it causesspack compiler find,spack external find,spack config add, etc. to be written into the spack instance by default instead of into~/.spack.~/.spackis a better choice if it's configured, as we do not know if the user actually owns the spack instance. It's also what people are used to, and it's going to cause a lot of consternation if we switch this default up on people.This PR introduces a new
prefer_modify: trueoption oninclude:that allows the including scope to hand off edit precedence to an included scope. The including scope is still modifiable if specified explicitly by name (e.g.,--scope spack) but if it is selected by default, we'll edit itsprefer_modifyscope instead.prefer_modify:option toinclude:spackscope specify the user scope asprefer_modify:.include:docs withversionaddeddirectives.userscopeprefer_modify:in$spack/etc/spack/include.yaml