Open liamdawson opened 6 years ago
A close integration with clap would definitely be a neat thing to have.
what are your thoughts on this integration, should it be like multiple --conf key=value parameters passed through the command line which will override the values in the config
If possible, it'd be great to reuse the names of fields in the struct, or allow them to be set via macros, so they can be used directly as flags (e.g. --key=value
). Otherwise, yeah, --conf "key=value"
.
sure will figure out how to do it through macros, still new to rust :) did initial version with multiple --conf parameter, let me know ur thoughts
https://github.com/tanujitghosh/config-rs/blob/issue-64/src/config.rs . - merge_args() https://github.com/tanujitghosh/config-rs/blob/issue-64/tests/file_toml.rs . - test case here
An integration with Clap will be the way to go in my opinion too. Did you start working on that? Otherwise, I might give it a shot.
It seems to me clap
integration could be implemented by providing a derive macro allowing a user to convert a struct
into a Config
value, which could then be merged with other sources in the usual way.
This would also allow the programmer to declare a single static
struct with all of the default values, and convert that into the base Config
for merger with other sources.
It should be possible to do a poor man's version of this already by implementing Serialize
for the struct produced by clap
and then deserializing the result into a Config
.
Are there any updates on this? Are there recommendations on how to use config-rs
together with clap
?
Are there any updates on this?
This project presently has no active maintainer AFAIK. I would be reluctant to adopt a crate for a new project when maintenance / development is halted.
I may eventually have time to assist with review and merging of contributions, but I'm not able to commit to a proper maintainer role here, nor do I have the ability to publish a new release I think even if I assist with PRs in future.
Despite the crates popularity, it's unclear when/if a new maintainer will arrive. You may want to look into other alternatives?
I rigged something up that supports jq syntax via the jaq crate
Rigged something up quick for my application.
I implement it two different ways. One uses the set_override builtin to this crate.
It can be be used like ./run -Xspotify.secret=blah
(which auto inserts the quotes) or ./run -X'matrix.auth={password:"password"}'
.
The second way pulls in jaq. It supports any transform jq does, which has slightly different syntax ./run -J'.spotify.secret="<blah>"'
There are ways to recursively merge records. ./run -J'.*{ <this whole object would be merged in> }'
I am able to do things like -J'del(.[].enabled?)'
to disable all my modules.
I can do -J'.playlist|=new(.id="<id>")'
to add things to a (possibly null) list, via a function (new) I added to the library.
This satisfies my desire to completely expose the config to the cli.
Now I'm wondering how this can be cleaned up, and whether there is a nice abstraction to be had with clap sub-commands.
EDIT: link to cleaned up version https://github.com/blueforesticarus/goontunes2/blob/b73a4a9d90322aee223046893fddbc4bac73c719/src/config.rs
Would you consider adding CLI support? A scenario I'm thinking of would work very nicely if you could override most/all of the config from CLI input, and it seems redundant to use clap to find the config file, get the contents of the config file, and then clobber those values with CLI inputs where they exist.
In the C# world, I'd add the https://www.nuget.org/packages/Microsoft.Extensions.Configuration.CommandLine/ package, which would then allow inputs in a number of forms, which would then override the config file settings depending on precedence.