3 ms·

> Secrets.yml is great Yes, but I still prefer Figaro[1], which makes it super easy to configure an app on Heroku, especially when the app has multiple environ

> Secrets.yml is great 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: $ rake figaro:heroku[my-app-staging] $ rake figaro:heroku[my-app-production] [1] https://github.com/laserlemon/figaro https://github.com/laserlemon/figaro

midas007 13y ago
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.
timdorr 13y ago
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. [1] https://github.com/ddollar/heroku-config https://github.com/ddollar/heroku-config
stiff 13y ago
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: https://github.com/jaroslawr/dynamic_configuration https://github.com/jaroslawr/dynamic_configuration 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.
- dasil003 13y ago
  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.
- haar 13y ago
  There's a typo in your README, I think the last exception mentioned should be MissingSettingException rather than MissingGroupException.
evolve2k 13y ago
Anyone had any luck loading their secrets.yml file into heroku, figaro style? Does Heroku even support the secrets.yml file at the moment?

midas007 13y ago

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.

timdorr 13y ago

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. [1] https://github.com/ddollar/heroku-config https://github.com/ddollar/heroku-config

stiff 13y ago

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: https://github.com/jaroslawr/dynamic_configuration https://github.com/jaroslawr/dynamic_configuration 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.

dasil003 13y ago
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.
haar 13y ago
There's a typo in your README, I think the last exception mentioned should be MissingSettingException rather than MissingGroupException.

evolve2k 13y ago

Anyone had any luck loading their secrets.yml file into heroku, figaro style? Does Heroku even support the secrets.yml file at the moment?