mirror of
https://github.com/facebook/sapling.git
synced 2024-10-09 16:31:02 +03:00
8290ea3545
Summary:
**Problem:** EdenFS has the classic hierarchical configuration design. We load from `/etc/eden/edenfs.rc` first, then `/etc/eden/conf.d/*` then `$HOME/.edenrc`. The latter can overwrite the former. At the end we have a complete view of the configurations.
`serde` is great, but it can't give us the information of whether it generated a field from `serde(default)` or from de-serialization. So we can't just deserialize then merge the configuration files. We need that information, and nor serde should give us that functionality.
`stack-config` is created to load configurations with serde. It automatically generates code with the intermediate data structure and taking care of merging of multiple configuration files. It derives a data type based on the original struct but wrap each field with `Option<T>` and mark it with Serde. Then it generates the code to merge and build the final concrete configuration data type.
It does not care what kind of data format the configuration file is, as long as it can deserialize into the generate optional type, it accepts it.
Example, say I have a file with this structure:
```
#[derive(StackConfig)]
struct Config {
path: String,
}
```
Then this crate will generate:
```
mod __stack_config_private {
#[derive(serde::Deserialize)]
pub(super) struct ConfigOpt {
path: Option<String>
}
...
}
struct ConfigLoader {
layers: Vec<__stack_config_private::ConfigOpt>,
}
impl ConfigLoader {
fn new() { ... }
fn load(&mut self, layer: __stack_config_private::ConfigOpt> { ... }
fn build(self) -> Config { ... }
}
```
See `examples/parse.rs` for usage.
Reviewed By: xavierd
Differential Revision: D26377547
fbshipit-source-id: 1e07d9867742913fd76ed4f765160f0035a2f2a3
|
||
|---|---|---|
| .. | ||
| examples | ||
| src | ||
| Cargo.toml | ||