When the config.gem statement was introduced I was pleased. It was great to have a centralized list of what gems were required by your application and with the rake gems:install task it would, in some cases, install the gems defined. More about that later, in another post.
After some time issues started to surface due to the lack of thought put into how to use config.gem. Here’s a list of some do’s and don’ts:
- Use absolute version references!. This is really important when you want to roll back. If you update gems as a part of your deployment and your config.gem statement has :version => “>= 0.9″ and version “1.0″ had api changes. When you roll back, you’re still going to pick up the new version and potentially go boom!
- Don’t put config.gem statements related to your application server. e.g. don’t put references to mongrel, passenger, etc… That’s a pain when you develop with passenger but deploy to mongrel boxes.
- Use :lib => false, if you don’t want Rails to require the gem.
- Do put testing related gems in your config/environments/test.rb, don’t put them in environment.rb (even if you use :lib => false, I think it’s a better practice. )
- Don’t install the gem then add the config.gem statement. Add the config.gem statement, then use rake gems:install. This will help you find any issues before you deploy.
If you have some best practices that have saved you, I would love to hear about them!
Thanks to Hashrocket for at least one of the above. Can’t remember where each one originated.
