Open spacekookie opened 6 years ago
default in: $HOME/.$BINARYNAME.$EXTENSION
overrided by an Option<Path>
This sounds good?
struct Confy {
cfg_in: Option<Path>,
cfg_out: Option<Path>,
}
impl Confy {
new(cfg_in, cfg_out) -> Confy... // if cfg_in.is_none() check for default
load...
write...
}
@gibix looks good but do we need to make the inputs optional?
Confy { None, None } maps to default values
Please use app_dirs or one of the replacements for the default config path. (I forget which is the "most bestest" at the moment.)
I think it's well worth surveying how different systems handle this. If this is going to be a default suggestion for how to handle config, it should not do anything "objectionable". In this case, I would call using $HOME/.something
objectionable: many people will object and say it should put stuff in $HOME/.config/something(
$XDG_CONFIG_HOME) or
$HOME/Library/...` on Mac.
For example, a typical binary on my (Debian) system will look for files under these directories:
/usr/share/something
/etc/something
$HOME/.something
or $XDG_CONFIG_HOME/something
depending on how well behavedIndividual settings in each location override the previous locations, so that all files are read in order, and configurations are updated.
Also in https://github.com/rust-clique/confy/issues/3#issuecomment-385886056, the subject of this issue was pointed out as a non-goal:
Absolute non-goals would for example be: [...] a comprehensive feature list like having multiple config files where fields from one overwrite fields in another.
I don't have strong feelings on whether it's in scope or not for a crate like confy, but I do have strong feelings on doing it right if it ends up being included.
Should it be possible to have a global config that is overwritten by a local/ user config, etc. And how would be the best way to implement this?
Suggested by https://github.com/rust-clique/confy/pull/2#issuecomment-392470342