Config - fallback to defaults

I’ve been experimenting with config files. The desired result is to have a config as compact as possible.
My question is if I can remove key-value pairs that are in the default state (the one generated by daemon without config file) and expect that these default values will be used.
Right now I would remove the whole server.stratum_mining_config as I have disabled the stratum anyway (which is default), or the whole server.pool_config as I don’t want to make any configuration of mempool myself and I would gladly use the defaults.
When I remove these sections, the daemon runs and it seems that it uses the expected defaults. What is bugging me is that there are some options that are required in config for the daemon to run. Some of them seem to be quite unreasonable, like log_to_file. Why wouldn’t I use some fallback to default? This is not some kind of security feature, it’s logging!
I have tried to look into the code, but it didn’t help as I am not proficient with rust. I have found some default settings, but I don’t know if they are used only to generate the config file or also as a fallback values

Summary: Is there some rule of thumb to decide which key-value pairs can be safely removed from the config file? Safely removed means that the default values will be used, said other way, removing the key is the same as having it in the config with default value. (Rule of thumb in this case means “usable for someone who doesn’t know much rust and doesn’t want to study the whole grin codebase right now” :))


Hi @josef-v,

I agree. There are definitely some inconsistencies in how we handle defaults and missing values in our config file.

This actually seems like a really good candidate for an issue on the repo itself -

If you could open an issue there basically restating what you are saying here then I’m sure there would be interest in picking this up.


For future reference: