3 ms·
> You will most likely want to create a default configuration file with sane and sensible default values the first time your program is executed. Please don't.
by theamk 4y ago
> You will most likely want to create a default configuration file with sane and sensible default values the first time your program is executed.
Please don't. Include the example configuration in your docs (/usr/share/PROG..) and mention it in the manual. Statistically user will have hundreds of apps installed but will only ever customize a small fraction them. So creating config unconditionally on first run is one of the worst contributors to homedir pollution.
Another argument is version upgrades: if you create configur on first run, you forever bake in the set of options present in that version. If later a new option is added, user will have no idea about it.
- _vufv 4y agoAlso, idempotency of a tool is a desired property that tool devs often invest a lot of effort in maintaining. Initializing default config on the first run is a trivial way to break it. It's much better to just have a sane implicit default value for each setting when config is not present. Then you can list the default config in your docs or offer a CLI flag --print-default-config or --copy-default-config.
- nyuszika7h 4y agoI agree, at least if there is nothing that absolutely has to be specified for the program to work.
- rozab 4y agoI don't see much of a problem with them being initialized in $XDG_CONFIG_HOME/<program>
- theamk 4y agoYou upgrade the software and it no longer works right. No one else reports the same issue. Turns out the version you tun for the very first time wrote a config in a location you never looked, and that config is incompatible with latest version.