Possible to have different configurations

[metasoarous]

I really like the idea behind omniconf, and have been wanting something like this that would make it possible to unify configuration from files, env variables, and command line arguments. The one catch is that for my application, I have subcommands/subsystems which run under a shared code base, and need to differentiate how options are processed depending on which subsystem is being activated, but still share most of the configuration. I'm a bit inspired here on the cli args side by the python argparse library, which is splendid. But I realize that this overall idea might be difficult to make compatible with the full functionality of omniconf. Do you see a way this could be made possible?

Thanks in advance

[alexander-yakushev]

Hi Cristopher,

I've indeed been thinking about making it possible in Omniconf to have separate configuration maps. I think it is possible to do so without breaking the backwards compatibility. I'll get back to you as soon as I have something.

I have subcommands/subsystems which run under a shared code base, and need to differentiate how options are processed depending on which subsystem is being activated, but still share most of the configuration.

Under this usecase, are you envisioning just separate configuration maps where you have to explicitly say which one you are getting values from, or do you have something else in mind?

[metasoarous]

Hi Alexander

Thanks for your response and thought on this.

In my situation, much of the configuration would be the same between subsystems, though details may vary between them. An ideal solution would give just the right room for overlap and differentiation/customization as needed. I haven't thought about this in a while though, so it may take some thinking for me to come back around to what I had in mind.

Thanks again!

[vmarcinko]

Just wanted to chime in that I also really like the general idea behind Omniconf, but only thing that bothers me is that configuration is one mutable singleton. I understand that there are some conveniences with this design, but as any functional programmer knows, there are also some drawbacks with global mutable singletons. Is there a chance that similar to say Clojure "hierarchies" (eg, "derive" function), there could be overloaded functions that can accept configuration as extra parameter ?

[pfeodrippe]

@vmarcinko @metasoarous @alexander-yakushev I've created a fork making all the applicable functions receiving an argument (config-comp) at https://github.com/pfeodrippe/omniconf, you can see the differences at https://github.com/pfeodrippe/omniconf/pull/1.

It's just an idea, but it's not backwards-compatible o/

All the tests are passing.