palkan/anyway_config

Is it possible to share a single app.yml with nested config for different classes?

jhirn opened this issue · 3 comments

jhirn commented

Hello. I am in the process of converting my project to use anyway config and really liking the gem so far. I have one question which may be possible with the gem as-is, but can't seem to get it to work.

Essentially, I'd like to avoid having one yml file per class so all actual settings are in one place. So given the following,

class AppConfig < Anyway::Config
end

class RedisConfig < AppConfig
   attr_config :url
   required :url
end

class  DomainConfig < AppConfig
   attr_config :admin_portal
   required :admin_portal
end

I'd like to have a single app.yml that looks like this

development:
  domain:
    admin_portal:  development.example.com
  redis:
    url: localhost:6379

test:
  domain:
    admin_portal:  test.example.com
  redis:
    url: localhost:6379

Rather than individual domain.yml and redis.yml files. I've been playing around with config_name and some other paths but stumped so figured I'd ask before going too far down a rabbit hole or giving up.

Thanks!

Hey!

Right now the quickest way to achieve this is to use secrets.yml—it already works the way you described.

Another option would be to add a custom loader.

I think, adding an option to load data from a single YAML file makes sense. Let me think about the possible interface/convention.

jhirn commented

Yes we are using secrets as well and that's probably what led to the desire. But secrets kinda come with their own headache so limiting that to API keys vs app configuration easier read in the clear.

Honestly after a couple days having a 1:1 corresponding .yml file is actually pretty nice so will probably just stick to that for now. Thank you so much for taking the time to respond and I'll keep an eye out if this becomes a feature. On a different/smaller project, having a single file as described above would be nice and tidy.

It feels something like config_name(:app, nested: true) may be a way to signal DomainConfig to use the domain entries in app.yml. Perhaps even config_name(:app, nested: :domain) would be a way for NotDomainConfig to use keys from the :domain root key, but not using the convention would bother me haha.

config_name(:app, nested: :domain)

I like the nesting idea (it popped up a couple of times but I wasn't able to focus on it to come up with a good interface).