It came up while documenting #2152 that Spack is inconsistent about which config scope is edited from command to command. Currently, the sort-of-inconsistently-implemented default behavior is to edit the highest-precedence available scope, which used to be user, but as of #2030 it's the platform-specific scope for the current platform (e.g. ~/.spack/bgq/config.yaml).

I figure I should bounce this off of people before editing it. See if you think what I'm proposing below is reasonable.

Currently there are 11 commands that take a scope argument. I've labeled them as either "read" operations or "modify" operations. I think they should behave as follows:

Read operations:

• spack config get
• spack compilers / spack compiler list
• spack mirror list
• spack repo list

I think all of these should show merged results by default, and allow the user to select a specific scope with --scope=<scope> if they want to.

Modify operations:

• spack config edit
• spack compiler add / spack compiler find
• spack compiler remove
• spack mirror add
• spack mirror remove
• spack repo add
• spack repo remove

I think instead of taking the highest precedence scope (which among other things might change from spack version to spack version if we implement additional scopes), we should implement this policy:

1. Introduce a default_edit_scope option in config.yaml, and out of the box it would be set to edit the user scope by default.
2. If the option is set to <scope>, commands should edit the generic <scope> config by default, but it should edit an architecture-specific <scope>/<platform> config if it exists. I think this is a) natural and b) prevents the user from getting confused if they, say, forgot they made a platform-specific config.
3. Finally, compilers are a special case (in that they are actually platform-specific) and spack compiler add/find should modify the platform-specific scope by default.

Does this policy seem reasonable? the other option would be to require a scope parameter for edit commands, but I think it's nice for users to be able to say, e.g., spack config edit or spack repo add without thinking about scopes.

@alalazo @davydden @adamjstewart @citibeth