Coming from a Spring background, I'm missing the possibility of expansion of environment variables referenced from within configuration files, giving an even more flexible approach next to overriding properties which is in itself a great functionality of the config crate.
Using this proposed change, there is no requirement to fully-qualify environment variable names that override the config files.
Spring also has support for a default value.
Both elements could be implemented, where :- splits the environment variable from the default, e.g.:
database:
host: ${DBHOST:-127.0.0.1}
port: ${DBPORT:-27017}Would you mind considering the proposal? I'd be glad to head from you.
There's a draft PR (#706) with a test which shows the effect.
Coming from a Spring background, I'm missing the possibility of expansion of environment variables referenced from within configuration files, giving an even more flexible approach next to overriding properties which is in itself a great functionality of the config crate.
Using this proposed change, there is no requirement to fully-qualify environment variable names that override the config files.
Spring also has support for a default value.
Both elements could be implemented, where :- splits the environment variable from the default, e.g.:
Would you mind considering the proposal? I'd be glad to head from you.
There's a draft PR (#706) with a test which shows the effect.