Being a warning about an excellent dependency management tool:
The release of Rails 3 ushered in a new era of gem management for Rails developers in the form of Bundler. This is a very good thing, since a) the previous state of affairs was pretty painful and b) Bundler is a shining example of the kind of great tooling the Ruby community does so well. It’s not just good for Rails 3 developers either:
Gemfiles can suck in dependencies from
.gemspecs, and Bundler can easily be used with legacy Rails.
Of course there are warts, and while Bundler’s are pretty minor, that didn’t stop them from eating half my week. One of Bundler’s neat features is the ability to specify a git repository for a particular gem. Instead of looking in gem repositories for the gem,
bundle install will check the repository out, look for a
.gemspec, and put the code in the right place. This is a nice way to track private gems that change frequently without the overhead of picking version numbers and shipping releases. As of Bundler 1.0, however, there’s no way to use
bundler package to pack a gem specified this way into a local package cache. This means that when you run
install on your production machine it has to be able to talk to the development git repository - at best, inconvenient, and at worst, entirely infeasible. The solution for us, for now, was to include our dependency as a vendored, submoduled plugin, and just include third party dependencies in our
Gemfile. This forces us to include all of the plugin’s dependencies in the top level
Gemfile, and isn’t at all ideal, but it does the job for now.
The takeaway is that if the workflow you are planning to implement using bundler needs to use
bundle package and
:git sources together, you’re out of luck for now. Happily, this wart is slated for removal in version 1.1, here’s hoping it ships early!