Nested settings overwrite defaults

[zetlan]

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.

[edrex-janrain]

👍

[neersighted]

👍

[dlite922]

real life issue with this bug:

defaults: 
  log: 
    file: /tmp/log.log
    level: 'WARN'

development: 
  log: 
    level: 'DEBUG'

first of all, that's not even valid YAML syntax, file and level need a " - " prefix to make a YAML list. , Even if you do this, when selecting 'development', the log file is not found. The whole log section gets overwritten, not the just the level key. NOT COOL! This bug alone makes settingslogic useless for me.

[TimPetricola]

👍

[sprad]

👍

[tkawachi]

👍

[johnagan]

👍

[defance]

👍

[mtarnovan]

👍

[mtarnovan]

I forgot about an old fork of mine of settingslogic which does this: mtarnovan@a03bf1e

This fork also introduces a dependency on Hash#deep_merge from active_support

[cofiem]

👍

[ccurtisj]

👍