Option overwriting doesn't work (for me, at least)

[smoofles]

Hiya,

I'm using an optional YML file with additional options as well as changes to the existing ones, which is loaded if it exists (doing so via Settings.add_source!("#{Rails.root}/config/lpl.yml") in my app's initializer). The problem is that I have the following defined in settings.yml:

lpl: 
  ..
  language_options:
    - de
    - en
  ..

while my own file has

lpl: 
  ..
  language_options:
    - de
  ..

I was expecting the result to be that Settings.lpl.language_options would hold ["de"], yet it still holds ["de", "en"]. Do I need to do anything besides

if File.exists?("#{Rails.root}/config/lpl.yml")
  Settings.add_source!("#{Rails.root}/config/lpl.yml")
  Settings.reload!
end

when loading the additional settings in my initlializer? Or should I be unloading all settings and include all the settings in lpl.yml, not just the ones that would add to/overwrite stuff from config.yml? And if so—how?

Thanks! :)

[tomkersten]

I am seeing the same behavior, but for standard filenames.

For example: I have a list key set in config/settings/production.yml, and on a test server I have the same key in config/environments/production.yml, but with a different list of values. I would expect that a file in config/settings/production.yml would override anything I have in the (as per the "Settings defined in files that are lower in the list override settings higher." statement in the README).

It appears this only occurs with lists (the lists are merged instead of replaced). I suspect this is the same issue, but haven't taken a look at the code yet...

[trobrock]

Same for me, I have two files

production.yml

assets:
  hosts:
    - somehost1
    - somehost2
  id: 1234

preview.yml

assets:
  hosts:
    - somehost3

Settings.add_source! "/path/to/production.yml"
Settings.add_source! "/path/to/preview.yml"
Settings.reload

results in

Settings.assets.hosts == ["somehost1", "somehost2", "somehost3"]
Settings.assets.id == nil

So mine also unsets the id field

[bgadoury]

I ran into this same issue on the current version today. I can see that arrays are intentionally additive (https://github.com/railsjedi/rails_config/blob/master/spec/rails_config_spec.rb#L111). The problem is that this behavior is inconsistent with the normal hash behavior as well as the documentation. It also means that we have to create a special case in our default config file so our production.yml config file can work correctly.

I'd be willing to cook up a change and a pull request if the authors agreed.

[fredwu]

@bgadoury It'd be great if you could provide us a pull request! Thanks! :)

[DannyBen]

Hey guys - I bumped into the same problem today, and found this 5 year old ticket with a 1 year old open PR.... is this fix happening? Or should we just consider arrays as non overridables for now?

[vinceve]

Hey Danny,

I had the same problem and made a fix around the same time this was fixed. But after that the deepmerge was extracted in a separate gem. And as the deepmerge gem isn't updated in a long time. I guess it's not in there.

That's why I still have a fork where I implemented this feature. You can find it here: https://github.com/vinceve/rails_config

I know this is not really a solution for the problem. But it's a temporary solution.

[DannyBen]

Thenks @vinceve - good to know. I am relying heavily on this config gem and its overrides. I hope to hear from one of the contributors about this ticket, to at least know whats the official policy in the canonical repository, and if there is a plan to change the current additive behavior.

[pkuczynski]

This has been fixed in #137