On 26 Nov 2020, at 17:44, Corentin CADIOU <corentin.cadiou@iap.fr> wrote:

We could of course fix the ambiguity by setting priority rules (ex. in this case, we could decide a field name is more specific than a field type, so it should have priority). What do others think about this?

That’s fine by me for reference, I was merely curious, I don’t have a strong opinion on how it should work.

TLDR; to ease the process of others weighing in, we have three options (I'd actually be in favor of Clement's option):

1. do not support local config files,
2. Clement's proposition: load the local config file (if any), otherwise load the global config file,
3. Corentin's proposition: load both the local config file (if any) and the global config file + provide a way to dump the current config via a CLI argument.

More details:

The way the PR is implemented currently is that it loads the config from ~/.config/yt/yt.toml, then it walks up the folder tree until it finds a yt.toml file. At the first match (if any), it reads it, overrides whatever was defined earlier and stops walking the tree up (i.e. at most one local yt.toml file will ever be read, in the same spirit as git stopping at the first parent folder that contains a .git directory).

If I am correct, your proposition is the following: if any local config file is found, then do not read the global config (~/.config/yt/yt.toml). If we were to adopt this proposition, which file should `yt config set foo bar` configure?

Here’s a suggestion:

- if no local config file is present already, store the new param in the global file

- else, error out and require that the command be rerun with either `—local` or `—global`

I think this covers every possible use case rather simply and don’t put us in a position where the feature is either hard to implement, document, or understand from the user pov.