Usage of the global configuration should be explicit

[sideninja]

Issue To Be Solved

The concept of the global configuration was introduced to allow you to have some global values you would use in any location where you execute the CLI. You can generate such a configuration by using flow init --global and then the CLI always checks for a local configuration and if that is not found try to loads a global configuration. This happens automagically and not explicitly which can lead to some weird edge cases where the value from global config is taken but the user thinks it was taken from the local config which could be missing. The fallback should be explicit as it doesn't hurt the UX much in doing so, but it improves the potential confusion which does hurt the UX a lot. There are also some security concerns to keep in mind.

(Optional): Suggest A Solution

Make sure when you want to reference a global config the command should include a global flag: --global or shortcut -g. Without this flag, the global config should not be used. If the global config is used it shouldn't load the local config.

[psiemens]

@sideninja Are there examples of other CLI apps that do something similar?

I'm just worried that this could cause more confusion: users may forget to include the --global flag and not realize that their global config isn't being applied.

Would it be possible to somehow indicate (i.e. via a stdout message) that config is being pulled from the global file?

I'm thinking of how git config works. Many git users have a global config file that is implicitly loaded, so that's naturally how I expect it to work.

[sideninja]

The fear I have is that using accounts with secret keys is a higher-risk operation than configuring your name (case of git). I believe if you are sending transactions you should be very aware of what account will actually be used for signing (case of shadowed account from local config or vice versa). Currently, this is just my hunch, so it can stay just documented here, but I have a feeling that there will be cases where the wrong account will be used implicitly and consequences will be wrong transactions on mainnet.

[bluesign]

I think the real risk here is accidentally sending some transactions with your main account instead of the local (project) account. This can mess up in an ugly way.

I think there are 2 solutions here, either we should accept global as the standard, or local as the standard usage. So far I think local is more commonly used.

Actually, I would add 2 flags, if the user wants to be clear on the intention of use, --global or --local. ( So some local scripts can fail if the user forgot to set up local flow.json etc )

Maybe if there is no local config, we can prompt the user for confirmation with a nice explaining message. Use Global Config? ( Yes / No / Always / Never ) I think this can also be a config setting.