Use dotenv gem for vulnerable and secret data

[sheerun]

https://github.com/bkeepers/dotenv

[teamon]

Nope, use https://github.com/laserlemon/figaro for all configuration.

[sheerun]

agree

[jandudulski]

Figaro :+1:

[jandudulski]

@szajbus added figaro already

[sheerun]

I agreed too fast. Any real reasons? Some people dislike figaro: https://github.com/revily/revily/issues/26

Also heroku's config is more silmilar to dotenv's way: https://devcenter.heroku.com/articles/config-vars

[sheerun]

OK. I self-answered my question. Figaro it is: https://github.com/sheerun/rails4-bootstrap/issues/28

[sheerun]

I changed my mind again. We should use both: https://github.com/sheerun/rails4-bootstrap/issues/28

[szajbus]

@sheerun I like the reasoning.

To summarize:

Figaro + config/application.yml for application-wide settings that rarely change (e.g. e-mail address).

dotenv + .env for environment-specific configuration and secrets.

Correct?

[jandudulski]

figaro also allows to set env specific values. @sheerun dotenv runs before figaro by coincidence or by a reason?

[teamon]

I see no real benefit in having two configuration systems. If some setting does not change (never heard of one) just hardcode it in config/environments/*.rb

On Monday, 19 August 2013, Jan Dudulski wrote:

figaro also allows to set env specific values. @sheerunhttps://github.com/sheerundotenv runs before figaro by coincidence or by a reason?

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/121#issuecomment-22841421 .

[sheerun]

@teamon The thing is: you can't overwrite configuration variables on-the-fly when storing configuration in config/environments/*.rb. You MUST reference them as config.SOMETHING. Dotenv nicely defaults ENV variables to .env (not overwriting it), so there is no problem with different referencing (You always use Figaro.env or ENV).

The other thing you might be suggesting is using Figaro for local configuration and config/environments/*.rb for permanent configuration (that is putting config/application.yml in .gitignore). I don't like this case either, because you reference configuration variables in totally different ways (config.xxx vs Figaro.env.xxx || ENV[xxx]). Imho application configuration (config/application.yml) is something different than application configuration (environments/xxx.rb). For example it is OK to include config.encoding = "utf-8" in application.rb, but totally weird to include config.admin_email = 'bob@foobar.org' in the same file. In my feeling application.rb and environments/xxx.rb serve for rails/gems configuration, while config/application.yml defines application configuration.

[teamon]

True, but I still think one lib (figaro) is enough.

On Monday, 19 August 2013, Adam Stankiewicz wrote:

@teamon https://github.com/teamon The thing is: you can't overwrite configuration variables on-the-fly when storing configuration in config/environments/*.rb. You MUST reference them as config.SOMETHING. Dotenv nicely defaults ENV variables to .env (not overwriting it), so there is no problem with different referencing (You always use Figaro.env or ENV).

The other thing you might be suggesting is using Figaro for local configuration and config/environments/*.rb for permanent configuration (that is putting config/application.yml in .gitignore). I don't like this case either, because you reference configuration variables in totally different ways (config.xxx vs Figaro.env.xxx || ENV[xxx]). Imho application configuration (config/application.yml) is something different than application configuration (environments/xxx.rb). For example it is OK to include config.encoding = "utf-8" in application.rb, but totally weird to include config.admin_email = 'bob@foobar.org <javascript:_e({}, 'cvml', 'bob@foobar.org');>' in the same file. In my feeling application.rb and environments/xxx.rb serve for rails/gems configuration, while config/application.yml defines application configuration.

— Reply to this email directly or view it on GitHubhttps://github.com/monterail/guidelines/issues/121#issuecomment-22843674 .

[jandudulski]

True, but I still think one lib (figaro) is enough.

Same here.

[sheerun]

So figaro and application.example.yml?

[jandudulski]

Ok for me.