Archive for July, 2010

Bundler is totally worth the hype

Let us all now sing a hymn of praise to Bundler. You know, like even more than we already were. Not that it needs too much more light shining on it, what with being a dependency to Rails and all, but I’ve had cause in the past few days to throw up my hands and make a joyful noise.

Now is a piece of software designed to do something as prosaic as dependency management going to get you hot and bothered all by itself? Probably not. It’s not going to be like when you discovered the beauty of Ruby’s iterators, or how to get the QBasic interpreter to give you the exploding banana game in MSDOS 5.x+.

But along those same lines, Bundler will help you reserve more of your mental compute cycles for things that matter and fill you with wonder, secure in the knowledge that you’ve chopped off a few big boulders from the pile of computational entropy constantly threatening to avalanche everyone in our industry into oblivion.

Examples:

Kids should come with “bundle install”.

Apps are complicated because you need all sorts of specific stuff to deal with them. That’s why Bundler was originally invented, obviously. But real-world scenarios are always valuable, and today I had to get a development version of the app I’m building for my main client running on the designer’s machine, and do it as fast as possible. While the designer is good w/ HTML/CSS, she doesn’t know thing one about Rails, rubygems, or the RVM-based sequestering of different Ruby versions, etc (another hymn another time for RVM). I got all that going for her, and then, with a mere two commands (one of which checked out the source code from the repo and therefore didn’t really even count), I bootstrapped the entire app at once, while surfing the web. “bundle install” for the win. That same process would’ve taken me (just for the app’s dependencies) about 45 minutes or so in previous incarnations of Rails. This way, it took less than three. And almost all of that was completely automated.

Specifying refs is a thing of beauty

Rails 3 rc1 came out a couple days ago. Like every other RoR cultist, I upgraded as soon as I heard. A bunch of crap promptly broke. Those wacky core team members! They love to make a boatload of commits on something and then call it a release candidate, just to keep us all sharp.

One of the things that broke was state_machine, which I rely on extensively in this the aforementioned app. So one upgrade from Rails 3b4 to Rails 3rc1 and I’m sitting there in a puddle of my own tears, with all my specs broken and no ability to run my seeds.rb file.

Thankfully, the gem maintainer rapidly came up with a patch. But he didn’t have a release ready yet. So what did I do? In the old days, I’d have to download his code at that Git reference and then put together a new gem on my own, keeping a vendored version that was seperate from the other versions of the gem I might’ve been using, etc etc. I’m sure there’s probably a better way to do it even under the old regime, but with Bundler, you simply pass in a reference to the commit where it’s been fixed!

So this

1
gem 'state_machine', :git => "git://github.com/pluginaweek/state_machine.git"

Becomes this:

1
gem 'state_machine', :git => "git://github.com/pluginaweek/state_machine.git", :ref => "1e5e04bb67be0b504a5fe9ca10a490286825d452"

That blew my mind even more than the dead-simple bootstrapping of my colleague’s development system. For working with libraries that are still in frequent development, and for fixing things like the myriad breakages that can occur when one version jumps up to be something else, this is a godsend.

So don’t bitch about Bundler, even if you’re tempted to in the beginning. Like everything else surrounding Ruby/Rails, it’s new and it takes some getting used to. But in the end, you’re likely to love it, and to wonder how you ever got along without it. Plus, this gives us yet another reason to laugh at Pythonistas, who still lack even a Rubygems equivalent.

Tags: