Managing Required Gems on Rails Projects 17
We’re starting a new project and I’m finding myself adding things to the code base that we’ve done in the past… hence the last few posts. As we’re doing this, I’d like to highlight some of the little things that we do on each project to maintain some consistency and in that process reach out to the community for alternative approaches.
I’m intrigued by the vendor everything concept, but we haven’t yet adopted this on any of our projects (yet).
What we have been doing is to maintain a REQUIRED_GEMS file in the root directory of our Rails application.
For example:
$ cat REQUIRED_GEMS
actionmailer
actionpack
actionwebservice
activerecord
activesupport
cgi_multipart_eof_fix
daemons
fastercsv
fastthread
feedtools
gem_plugin
image_science
mongrel
mongrel_cluster
mysql
rails
rake
RedCloth
Ruby-MemCache
soap4r
uuidtools
Everybody on the team (designers/developers) knows to look here to make sure they have everything installed when beginning to work on the application.
This has worked fairly well from project to project but since we’re starting a new project, I’m curious if anybody has some better ways to approach this. Should we look more seriously at the vendor everything approach or are there any alternative approaches?
Enjoying the content? Be sure to subscribe to my RSS feed.
We’ve been using the gemtracker plugin, which allows you to define the required gems and versions in config/gems.yml, and then raises an error when the server starts up if a dependency is missing. Also provides rake gems:install to install all the dependencies.
It’s worked out really well and is one of the reasons that we haven’t vendor’d everything.
GemInstaller looks pretty robust.
Don’t forget you can have cap require certain gems when deploying too.
Use geminstaller. We’ve been using it for our project (as has every project at the pivotal office) for the last several months. It’s awesome.
I like the FrozenGemsGenerator
I like the FrozenGemsGenerator
We’ve had a lot of luck with vendor everything. We unpack gems (with version numbers intact in the directory name) into vendor/gems and have a one-liner in environment.rb that adds each gem directory to the load path.
It’s great to be able to know not only which gem we’re using but which specific version.
It’s nice to have your team begging to work on your application!
@raymond: hah! nice catch. :-)
Another vote for GemInstaller. As compared to others, it also solves the platform specific gems problem, as well as deals with ensuring the gems you specified are what are actually on your app’s load path, even if you have multiple versions of the same gem installed. Here’s some more info I wrote up about it.
Thanks for the link brandon :)
+1 for GemInstaller. Also, I put a dependencies.rb file in config/initializers to require other non-gem files.
We love cap deploy:check
GemInstaller does look like a good solution. On that note, here is an interesting discussion on Rails Trac regarding a potential addition to RoR core http://dev.rubyonrails.org/ticket/11167
I don’t see gem versions listed, though. You seem to be assuming that there is backwards-compatibility.
Have you ever looked at http://rubyforge.org/projects/plugems Plugems? It’s what we use at Revolution Health.
Hi,
Thanks for the GemInstaller propz. Full disclosure – I currently have broken tests against the new 1.1.0 RubyGems release (http://ci.thewoolleyweb.com/), which I’m working on. Strangely, I was green against trunk the day before the release, so I dunno WTF. I hope to have this fixed soon, limited only by my programming skills and ability to stay awake hacking after putting the kid to bed. Contributions welcome ;)
You can manage required gems in EDGE now: http://dev.rubyonrails.org/changeset/9140/trunk/railties/CHANGELOG
Rake tasks are also provided to installed all the required gems.