After going through the hell of chasing down gem after gem for a Rails project at work, then discovering that it actually uses a few older gems than what are currently released, I decided to write the gemtracker plugin.
Short summary: you write config/gems.yml, which is nothing more than a YAML hash of gem names and versions. When Rails initializes (but before it starts loading any of your custom initializers), it loads those gems at the requested version.
How is this better than just specifying, for instance, gem rspec, '1.0.1' in the top of your environment.rb? When you run Rails, it will throw an exception that tells you all of the missing gem versions at once, rather than having to go through the tiring loop of running script/server, checking the exceptions for the missing gem, installing it, and repeating ad nauseum. My hope is that it will also encourage developers to explicitly list the version of any gems used, which is a good practice in general for writing production apps.
It also provides a singular rake task, gems:install, which installs any versions of required gems that you’re missing (run it under sudo if you need root privileges). This should prove useful for larger projects with several developers. It should also be pretty trivial to add a Capistrano task that runs rake gems:install during an upgrade, ensuring that the environment there is identical to the developers’.
Hope this helps some of you out there.
Update: Apparently, init.rb went missing when I did some layout reorganization a few days ago. Thanks to an anonymous reader and DerGuteMoritz for bringing this to my attention. This has now been fixed.
DerGuteMoritz | 27-May-07 at 7:36 am | Permalink
Great idea, I’ve installed it to my rails application skeleton already. One thing though: I’ve intentionally uninstalled one of the gems listed in config/gems.yml for testing but the server still starts up without hesitation. It seems you forgot to supply an init.rb - or am I mistaken?