-
Notifications
You must be signed in to change notification settings - Fork 236
Re-thinking: Support deserializing key-value config data #322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I'd love to work on this, I've previously worked on an interpreter is Rust before, that had internal type system. I feel like I could port some of my code from there. |
I am interested in this thinking. A typical scenario is that loading from a backend key-value config service and needs to be merged to the 'layered' local configs. My previous solution was mapping those key-value string typed configs to an INI format, then later deserializing them to a structured type. There are problems I am thinking about. How to define the typed value, especially the The # key-value
foo.bar.[1] = 42
foo.bar.[2] = 43
fun_a.enabled = true # Yaml
foo:
bar:
- 42
- 43
fun_a:
enabled: true # env
# maybe like this
PREFIX_FOO_BAR_[1] = 42
PREFIX_FOO_BAR_[2] = 43
PREFIX_FUN_A_ENABLED = true #[derive(Deserialize)]
pub struct Config {
foo: Foo,
fun_a: FunConfig,
}
#[derive(Deserialize)]
pub struct Foo {
bar: Vec<u32>,
}
#[derive(Deserialize)]
pub struct FunConfig {
enabled: bool,
} This means it needs a structured key syntax definition. Something like this will be compatible with the other typed format (JSON, Yaml, etc). Furthermore, this seems like an extension of the |
Um... I am not sure we're talking about the same thing here. The intention of the issue is that we do not deserialize to an internal data store, but to the normal data types that each format exposes (think As far as I understood, you're talking about writing an own data format, but that was never the intention! 🤔 |
config-rs should be able to support key-value configuration data of the following types:
Something like
Should be the basis of all operations. This data format can be deserialized from different sources and be used for the "layering" functionality later.
It might be even possible to implement in a non-owning way.
We should keep the currently supported formats as supported formats in the future.
That entails:
The text was updated successfully, but these errors were encountered: