That’s fine by me for reference, I was merely curious, I don’t have a strong opinion on how it should work.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?
Here’s a suggestion:TLDR; to ease the process of others weighing in, we have three options (I'd actually be in favor of Clement's option):
- do not support local config files,
- Clement's proposition: load the local config file (if any), otherwise load the global config file,
- 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?