Manually creating/editing the config file?

[shinglyu]

(The Discord chat room doesn't seem to load, so I'm asking here)

In the design philosophy of confy, is the developer allowed (or encouraged) to edit the config file manually?

I'm asking because based on the documentation, the creation of a new config file is done by:

1. Implement the Default trait on the config struct
2. Run confy::load()

Editing the config is done by confy::store(). So the creation and update of the config are done through Rust code.

So if I understand correctly, this crate is used to persist configurations between different executions. But not as a config file solution similar to dotenv or rc files (e.g. .bashrc, .vimrc), where people write a configuration file manually so they can override the program's behavior without re-compiling the code?

If the user is encouraged to directly edit the config file instead of using the confy::store() function, then I believe we need to put more thoughts into how a first-time user can create a new config file. Maybe the developer needs to implement a separate "first-time configuration wizard" CLI that help the user choose the configuration? It would be great to clarify the common use cases and patterns in the documentation besides the two core APIs.

[danieleades]

to add to this, the store and load functions are not currently symmetrical, in the sense that the store function can handle the case that the configuration does not implement Default, but the load function does not.

From the docs-

You can also use this function to create a new configuration with different initial values than which are provided by your Default trait implementation, or if your configuration structure can't implement Default.

How would one use confy on first run of an app, if the config struct can't implement Default?

What i really need is a confy::try_load(name: &str) -> io::Result<Option<T>> which might return the struct, might return an error, and might return nothing (if it hasn't been initialised yet). Then I can prompt the user to set the required configuration via the CLI and store this. This is an all or nothing approach though, i don't get per-field granularity this way.

I suppose I could also handle this case by having an 'inner config' with optional values (which can implement Default) and an 'outer' config without optional values. I would then implement TryFrom to get from one to the other, and prompt the user for missing values on any errors. This is starting to smell like a custom derive, but I imagine it's a common enough use-case. Is this the kind of thing this library would support? If not, are there other libraries that would?