Making Configuration Files with YAML: Revised

So back in July 2007 I posted a blog on making configuration files with YAML, and I’ve been noticing a lot of readership on the old article. Because it seems that a lot of people are reading it I felt it was important to show how I apply this nowadays.

First I put my config.yml file within the /config/ directory within my Rails application. It looks something like this:

development: &non_production_settings
  :google_analytics:
    :api_key: "[Enter Google ID]"
  :site:
    :title: "[Title]"
    :address: "http://localhost:3000/"

test:
  <<: *non_production_settings

production:
  :google_analytics:
    :api_key: "[Enter Google ID]"
  :site:
    :title: "[Title]"
    :address: "[Address]"

Then, I create a new file called load_config.rb within the /config/initializers directory. You can name the file whatever you want – that’s just what I call it. This is where the actually YAML loading is going to happen – and this is what it looks like:

raw_config = File.read(RAILS_ROOT + "/config/config.yml")
APP_CONFIG = YAML.load(raw_config)[RAILS_ENV]

Now any time I want to all one of these variables I just call it like:

<%= APP_CONFIG[:site][:title] %>

12 thoughts on “Making Configuration Files with YAML: Revised”

Jason says:

February 2, 2009 at 4:23 pm

Thanks for the quick yaml config how-to. I am new to RoR and this was exactly what I was looking for.

Reply
Pingback: Making Configuration Files with YAML « Innovative Thought
cheapRoc says:

February 3, 2009 at 11:00 am

AppConfig = OpenStruct.new(YAML.load_file(“#{RAILS_ROOT}/config/app_config.yml”)[Rails.env].symbolize_keys) if require ‘ostruct’

So you can do something like…

AppConfig.site_title

Not sure how it works with your nested Yaml config file though.

Reply
jyoseph says:

February 2, 2011 at 9:12 pm

This is freaking awesome. I’m also a rails newb and this was drop dead simple.

Question, the file will only be read once right, when the app starts? (as opposed to every request)

Reply
1. Tim Knight says:
  
  February 2, 2011 at 9:38 pm
  
  jyoseph,
  
  Glad you liked it! I hope it is helpful for you. The code is run as an initializer so it runs on application initialization storing the information into a constant. While it might run with each request in development mode (can’t recall) it should only run on initialization during production mode.
  
  Reply
jyoseph says:

February 2, 2011 at 11:35 pm

Thanks for the clarification on that, I’m actually more excited than I should be about this, hah! It allowed me to have some app-specific settings that I would not want to commit to github. I saw some other solutions (gems/plugins) but all seemed too heavy for what I needed. Thanks again!

Reply
1. Tim Knight says:
  
  February 3, 2011 at 8:29 am
  
  You’ll actually find something like this in most larger Rails applications (from my experience). It’s great for API keys and all the various configuration details that might differ between the multiple environments. Ryan Bates (of Railscasts fame) has a similar config file system in his nifty_generators nifty_config feature at https://github.com/ryanb/nifty-generators. Enjoy!
  
  Reply
Dc says:

April 14, 2011 at 7:54 pm

Hi, this is a great article for newbies like me. I’ve actually looked all over and this seems to be the best resource for understanding.

I have a few questions if you don’t mind to clear some things up.

First off, do you include config.yml in your .gitignore file so that it is private and not tracked and when pushing to a remote repo on github? (for private things like API or s3 keys)

And if you do add config.yml to your gitignore file. When pushing up to a cloud server such as heroku, how does heroku have contact with your config.yml file if it’s not on github.

Thanks again for the helpful post!

Reply
1. Tim Knight says:
  
  April 15, 2011 at 7:45 am
  
  Hi Dc,
  
  That’s a really good question. When it comes to whether or not you would add config.yml to your .gitignore personally I feel it just depends. It depends of course first on what the material is you are using in your configuration and secondly it depends on if you repository is public or private. If you do leave it out I would suggest creating a config.sample.yml with test data in it so other contributors on the project can understand the structure of the file. When it comes to deployment I would say that if you are running a public project where the file does not exist I would likely consider looking for a way to create the file within my deployment script. A good example of that would be EngineYard’s chef recipe for creating the database.yml file.
  
  Reply
Pritesh says:

May 16, 2011 at 12:48 pm

cool…I am newbie to RoR and this article made my day , was looking for somthing like this to make the code look simple and flexible… thanks a lot Tim !

Reply
Peter Nixey says:

June 1, 2011 at 5:41 am

This is really useful thank you. After looking at this I wondered how you could DRY the config file up and discovered that you can use ‘anchors’ and ‘references’ to do this.
(http://en.wikipedia.org/wiki/YAML#Language_elements)

For instance, if the site title is the same in development as test and production then you can define it as follows:

development:
site_title: &title My new website

test:
site_title: *title

production
site_title: *title

Thanks for the post and hope this is helpful :)

Reply
1. Tim Knight says:
  
  June 1, 2011 at 7:18 am
  
  Thanks Peter. Yes you can reference other settings by setting there name with &name. You can see that in use where I’m importing all of the development settings into the test environment. You pointed out however that you can set individual items as well—thanks for digging into more details on the concept.
  
  Reply