Matt Smith's Blog

Software Engineering related topics

Introduction to Bundler

| Comments

Over the last few years I have become a huge fan of using Rake as my build scripting language of source. It is rich in many aspects, which I don’t care to dive into right now. Since it runs on Ruby you have access to all the various gems already developed.

I recently started a new job at Dovetail Software, and they were already using Rake; however, they weren’t using Bundler. This is where my headache began which prompted this post. I proceeded to install all the gem dependencies manually by simply running gem install rake. The latest version at the time that I did that was 10.0.2 and the version that was previously developed against was 0.9.2.2. Although the differences between these two different versions was minimal, there was one error that I got simply because I was on a newer version then all of my colleagues.

Bundler was designed to mitigate this problem. Bundler is a ruby gem version management solution. The best part is it only requires two additional files to the root of you project directory, one which you write and the second that is generated by Bundler. I know I just said generated, which is generally a bad thing when it comes to code, just bear with me.

The first file to create is a file named Gemfile no extension type just exactly as I wrote it. This file is used to specify the acceptable gems and versions that you intend to use. You can find detailed instructions on the content of a Gemfile here.

After you have the Gemfile you can generate the second file I mentioned Gemfile.lock. This is created by running bundle install, this command will do one additional thing on top of creating the file. Since Bundler is a gem version management utility the command will also download the gems for the versions you specified, along with those gems dependencies. The Gemfile.lock file will contain a list of all the gems installed and the exact versions that were installed.

Here is where the magic begins. Commit those files and move over to your buddies computer. Have him pull down that commit, and run bundle install The Gemfile.lock will not be changed this time, instead Bundler will install the gems with the exact versions as specified in the Gemfile.lock. Now if you leave those gems alone for a while and you either hire a new employee, get a new computer, yatta yatta yatta. Run bundle install on that new computer and it will use those same versions, even if a newer version exists.

Now when the time comes that you wish to update a gem, just run bundle update <gem>. Bundler will modify the Gemfile.lock, commit this and all your colleagues will know what version you are now using.

If you have multiple projects using various different versions of gems Bundler is there to rescue you again. When running Ruby it will attempt to use the latest version of an installed gem. If you preface your command execution with bundle exec <command>, then Bundler will ensure that the versions specified in the Gemfile.lock will be the ones that are pulled in with a require statement.

Now you only have one additional thing to do, and you will never accidentally require in the wrong version of a dependency. Simply put require 'bundler/setup' at the beginning of you entry ruby script. Bundler will then fail if the versions specified in the Gemfile.lock are not installed. It will prompt you to run bundle install. Now when you update a dependency and commit it, your colleagues will not be able to accidentally run the updated scripts.

I don’t intend for this to be an all inclusive documentation on Bundler, you can find that at the official Bundler website here, but hopefully this will server as a launching point to get started with using it. It has been and will continue to be a great tool to ensure your entire development team is on the same page.

Comments