mehcode
Make path::Expression module public
I'm working on feature control library and would like to take dependency on Value and path::Expression. Unfortunately, path::Expression is not public module. It is useful even outside the context of config-rs. Can you make it public in the next release?
Heyo :) I figured that I would rather re-use this old closed issue instead of creating a new one.
My particular use-case in question would be as follows:
I'm currently writing a configuration crate for a larger ecosystem, which will also expose a small binary to allow querying and setting configuration values. Querying, to allow easy access to configuration data in bash, python or other languages by simply shelling out. And writing to allow users to edit their config from everywhere (git style).
For setting variables, I planned to use toml_edit.
As it would be weird to have two different syntaxes for reading/writing, I planned to use config-rs's Expression to both validate that the config path actually exists before attempting to set it, and then use the Expression's path to actually set the value via toml_edit.
I've seen that config-rs might come with edit functionality included (#321), but until then, having access to Expression, would allow us to re-use that functionality for our own editing logic :)
Whats not quite clear, are you using config underneath your own configuration crate or are your implementing everything and just wanting to reuse our Expression?
As for paths and settings, while not ergonomic, another alternative for what to expose to users is to use TOML itself. cargo --config <key-value> evaluates <key-value> as a line in a TOML file. The main annoyance is quoting because strings require quotes and then you need to escape those in your shell. I think I also expose dotted key path parsing so you could use that for getting as well (which cargo doesn't quite handle atm).
Hey, thanks for the quick response :)
The crate would just be a small wrapper around a config struct with some nested configs that are initialized and handled via Config. So I want to use the full config-rs crate, including the deep nested path lookup of config. (E.g. my-config-bin query "config.subconfig.my_option" )
For convenience and correctness, I would then use the same syntax for the setter as well, which would require access to the Expression to prevent duplicate path parsing (E.g. my-config-bin set "config.subconfig.my_option" "some_value")
From what I understand, the cargo --config flag overrides the configuration flag for that call. My current goal is to actually edit configuration files, without loosing formatting or comments.
To summarize, the usecase of the crate would be:
- A configuration struct (nested), exposed as libarry.
- A binary with
- A subcommand to read hierarchic config files from the filesystem and query specific fields of that struct utilizing
config-rs's path lookup. - A subcommand to write specific fields to one of the hierarchic configuration files, without loosing formatting or writing non-existing fields/invalid data.
- A subcommand to read hierarchic config files from the filesystem and query specific fields of that struct utilizing
I'll at least re-open for considering and exploring this but not fully ready to commit.