Static config file

[jayrmotta]

I noticed the file mujina-miner/src/config.rs has the following functions to load config from files:

impl Config {
    /// Load configuration from the default location.
    pub fn load() -> anyhow::Result<Self> {
        // TODO: Implement config loading from /etc/mujina/mujina.toml
        // and ~/.config/mujina/mujina.toml with proper merging
        unimplemented!("Config loading not yet implemented")
    }

    /// Load configuration from a specific file.
    pub fn load_from(_path: &Path) -> anyhow::Result<Self> {
        // TODO: Implement TOML parsing
        unimplemented!("Config loading not yet implemented")
    }
}

The first says files should be loaded from /etc/mujina/mujina.toml and ~/.config/mujina/mujina.toml "with proper merging". Can we clarify what proper mergin is? What happens if we have clashing keys in different files? Is there a precedence like user (in the home folder) overwrites global (in /etc) ones?

Regarding the load_from function, is it meant so that people could have "portable" config files and perhaps point to it via CLI arguments?

I believe this is a simple implementation that reduce hardcoded values throughout the codebase and open customization possibilities for mujina's users.

[jbride]

The first says files should be loaded from /etc/mujina/mujina.toml and ~/.config/mujina/mujina.toml "with proper merging". Can we clarify what proper mergin is? What happens if we have clashing keys in different files? Is there a precedence like user (in the home folder) overwrites global (in /etc) ones?

Yes, I would expect this to be the case.

Regarding the load_from function, is it meant so that people could have "portable" config files and perhaps point to it via CLI arguments?

Correct. ie: a podman / docker environment where a custom mujina.toml config can be mounted to the container and read at startup. If provided, this mujina.toml should take precedence over all others.

[rkuester]

Thanks for starting this. It's the question that grew into MIP-0001, where the "proper merging" and precedence you asked about is now specified as a layered cascade. Continuing in #57; closing this as superseded.