[RFC] CLI for config related commands

[chshersh]

Blocking #72

tool-sync works with the config and it's desirable to have multiple features around easy work with the config. Currently, tool-sync has a single command default-config to print the default configuration to stdout and the --config option to specify the path to the config.

This feels a bit awkward so I'd like to start an RFC about a better design of config-related CLI commands.

This RFC talks not only about existing features (at this point we don't have many of them) but also about potential future features.

[current] Option 1: default-config

The idea is to prefix all commands with the default- string and use different options:

• tool default-config: to output the content of the default-config
• tool default-config --path: print path for the
• tool default-config --show: show the content of the current configuration file under the default-config --path

Pros

✅ Already implemented (default-config) ✅ Has no conflicts with the global --config

Cons

⛔ Not extensible to non-default commands ⛔ More complicated interaction with the global --config option: See discussion:

• https://github.com/chshersh/tool-sync/pull/62#discussion_r964763278

[proposed] Option 2: config --bla

An alternative option is to introduce a new config command and make the --config flag local to other commands (so there's no tool --config=... config command). The behaviour:

• tool config: Interactive configuration of tool-sync (in potential future???)
• tool config --default: print the default config content to stdout
• tool config --default --path: path to the default configuration
• tool config --default --show: show the content of the default config
• tool config --show --path=path/to/config: show the content of the config in the path
• tool config --path=path/to/config --set-store-directory='$HOME/.local/bin: update config field store_directory (maybe good for tooling?)

Pros

✅ Single entry-point for all config-related commands (covers both default and non-default options)

Cons

⛔ Can be confused with the global --config flag: requires making this flag local to the subcommand (breaking change) ⛔ Requires changes and duplication of the `--config

Other ideas?

If you have any thoughts, please, feel free to share your feedback!

I'll leave the current behaviour (Option 1) as it is for now until we get more information on how to improve config-related options and what features are desirable.

[MitchellBerend]

I personally like having the global --config flag. It does not make sense for the default-config sub command but I can see it being useful for most other sub commands. If this program gets expands functionality I assume all config options will be put in the .tools.config.

Having the ability to check in the .tools.tomlinto a a separate git repo would also play nice with tools like ansible/salt-stack. Thats the way I personally use it.

---

[Feature] Another option could also be adding an environment variable where the config is stored. This could be added as a way to set the config path besides the --config flag

Pros

• No breaking change

Cons

• Might make debugging the tool more complicated since the environment variable is not super apparent at first glance

[chshersh]

I propose to keep the default-config command and implement the --path option for it.

The truth is, I'm not sure that we'll want to add more complications to the config commands just to support something that is easier to do by simply editing the config. So I don't think we'll have the set-config or other commands.

Another sanity check: it's not even clear what tool config on its own should actually do. It doesn't make sense and it's too generic. So let's keep Option 1 and I'll create followup issues.