Consider this settings.yaml file:
defaults: &defaults
foo:
bar: "baz"
q: "bert"
development:
<<: *defaults
foo:
bar: "xyzzy"
The intention is to do a multi-level merge of the defaults, so that in development you get Settings.foo = {"baz" => "xyzzy", q => "bert"} -- in other words, dev selectively overwrites the settings hash tree.
What you get instead is Settings.foo = {"baz" => "xyzzy"} -- the merge operates on the "foo" key, and doesn't check to see whether the value of Settings.foo may be a hash.
I'm getting around this now by using naming conventions (i.e., all the "foo" settings are foo_something) and putting all config options on the top level, but it would be much cleaner if nested settings were selectively merged.
Incidentally, this may be more or less a duplicate of issues #4 and #16, and I think there's at least one pull request to address this issue already.
Consider this settings.yaml file:
The intention is to do a multi-level merge of the defaults, so that in development you get Settings.foo = {"baz" => "xyzzy", q => "bert"} -- in other words, dev selectively overwrites the settings hash tree.
What you get instead is Settings.foo = {"baz" => "xyzzy"} -- the merge operates on the "foo" key, and doesn't check to see whether the value of Settings.foo may be a hash.
I'm getting around this now by using naming conventions (i.e., all the "foo" settings are foo_something) and putting all config options on the top level, but it would be much cleaner if nested settings were selectively merged.
Incidentally, this may be more or less a duplicate of issues #4 and #16, and I think there's at least one pull request to address this issue already.