Yes, but I still prefer Figaro[1], which makes it super easy to configure an app on Heroku, especially when the app has multiple environments on Heroku:
I've used figaro but recently switched off in favor of a combo of foreman, dotenv, and heroku-config[1].
- Foreman is great because you'll get parity with how Heroku runs things (they use the same Procfile and read a .env file). Plus, if you have separate workers, then you can easily boot up your app.
- Dotenv is drop-in for Rails and supports .env usage outside of foreman.
- The heroku-config plugin is great because it works throughout your system and can also pull down the current config from Heroku.
Yeah we use figaro for local dev and non-heroku production apps to override already sane defaults (extra cruft in config/ and initializers to do that), which the "variables" table can override and is app-admin configurable.
I never understood why you would use YAML for storing settings. In fact, I observed that because of YAML devs are less likely to extract things into configuration settings, especially adding a setting seems to involve a manual server restart. I wrote a gem that's IMO much better:
Settings are configured in Ruby, split into separate files/groups, are easily overwritten per-Rails-env and per-particular-installation, in development environment they are reloaded automatically after a setting is added etc.
I think it's largely a case of cargo-culting a Rails core decision made somewhat arbitrarily before Rails was even released (ie. config/database.yml).
Theoretically I suppose YAML is supposed to be a human-editable data format, but after trying to get translators to translate app strings in YAML format I decided that YAML is worthless as anything except an interchange format, and even there, primarily for Ruby because of its rich semantics.
Yes, but I still prefer Figaro[1], which makes it super easy to configure an app on Heroku, especially when the app has multiple environments on Heroku:
[1] https://github.com/laserlemon/figaro