from Hacker News

Rails Environment Variables

by aviflombaum on 12/13/12, 10:24 PM with 24 comments

• by venus on 12/13/12, 11:45 PM

  As far as I can see this article is rather misguided. The author seems totally unaware of the existence or purpose of these files:

    config/environments
    ├── config/environments/development.rb
    ├── config/environments/production.rb
    └── config/environments/test.rb
  

  Put all this stuff in there.

  edit: I see the source of this misunderstanding. The author states:

  > Rails applications should be “turnkey”; that is, deployed anywhere without modifying code

  This is an ideological statement with no basis in reality. If you have to jump through all these hoops in order to trick your app into running as expected without modifying code - you're probably Doing Things Wrong™.

  A better approach might be to make a private fork of the project you wish to deploy, modify the code as needed, deploy from that, and periodically merge from upstream.

• by habosa on 12/13/12, 10:58 PM

  This is extremely useful. A TON of people learn Rails from tutorials and never hear about issues like this. Then they go and push to GitHub and expose their login information for something secure. It took me too long to figure this out, thankfully nobody really looks at my Rails projects on GitHub (I hope).

• by DanielKehoe on 12/14/12, 3:33 AM

  Taylor Mock and I are the authors of the article. Here's why we wrote the article. And why we suggest an alternative to using the Unix shell to set local environment variables.

  The rails-stripe-membership-saas example application [1] from the RailsApps project has become very popular. I've been getting lots of requests for help stemming from problems setting local environment variables. Personally, I prefer to use the Unix shell to set local environment variables such as email account credentials and API keys. Always has worked for me. Apparently some people have trouble (perhaps complications with rvm or just plain ignorance). Anyway, telling newbies to school up is not a solution. So Taylor Mock came up with a trick to use Ruby to set local environment variables from a Rails application without involving the Unix shell.

  It has some advantages. If the variables are set in the shell, the code just works. If the shell environment is a mess, the developer can use a local_env.yml file to set the environment variables.

  There are several other valid and appropriate approaches (a .env file, a dotenv gem, etc). Also, there is a whole mini-industry of clever gems for setting constants and configuration variables in Rails. This is different. This is just intended for variables such as email account credentials and API keys that shouldn't be hardcoded.

  I describe the motivations for the article in a RailsApps blog post [2].

  [1] http://railsapps.github.com/rails-stripe-membership-saas [2] http://blog.railsapps.org/

• by petewarden on 12/14/12, 12:11 AM

  I've wrestled with this pattern (anti-pattern?) myself. One key advantage is that I can run plain Ruby unit tests outside of Rails, as long as I make sure the right environment variables are set in my shell.

  I'm conflicted about it though; I hate being out of the mainstream on something as fundamental for maintenance as this and I have to jump through hoops to get Apache to set my environment variables.

• by dasil003 on 12/13/12, 10:45 PM

  Interesting article as I haven't gone down this path.

  I tend to favor YAML files for configuration, and symlink them in the case of security concerns like private keys.

  To roll up a standard access pattern in our app which has dozens of configuration files, I wrote this which allows local developer overrides via xxx_local.yml:

  https://gist.github.com/4280751

  I'll probably gemify it at some point.

• by itsbonczek on 12/14/12, 12:19 AM

  I've been really liking the foreman approach with Heroku. It's super easy to create a .env file that contains environment variables that can then be git-ignored.

• by calgaryeng on 12/13/12, 10:57 PM

  You can also check out the `figaro` gem which provides some pretty handy functionality.

• by mickeyben on 12/13/12, 11:13 PM

  I love this hack. We're using it a lot at our company.

  exemple:

    if ENV["NO_REDIS_CACHE"]
      config.cache_store = :null_store  
    else
      config.cache_store = :redis_store  
    end

• by danso on 12/13/12, 11:12 PM

  Dear god....this has always been a point of confusion for me, in that if you look up best practices, you'll find a multitude of contradictory advice. Well, I guess all solutions could be equally safe and sound...but it was still confusing and something almost never covered in beginner how-tos. I'm glad I'm not the only one who was always mildly confused.