Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

Bundle(r) Yourself… and Get Ready to Cruise!

On a current project, we’ve just switched from GemInstaller to Bundler for managing our application’s gems.

All in all, the transition was painless… in our development environments. Of course, in order to keep things on running smoothly on the continuous integration box, we amended our rake cruise:spec task to start by running sh "gem bundle".

So, wonderful! Any changes to our gem dependency list will picked up when cruise starts and made available for that “build”; there’s no need to log in and make any manual updates. Right?

Not quite. We’re using the disable_system_gems option and, in that case, Bundler (very intentionally) modifies your GEM_PATH such that only “vendor’d” gems are available to the application. Which of course means that Bundler itself, being “a gem to bundle gems”, is unavailable when that sh "gem bundle" command is run.

Our solution: bundle Bundler, obviously! That’s right, in our Bundler Gemfile we’ve included gem "bundler". Now, after a single manual execution of gem bundle to pick up the bundled Gem Bundler gem bundle (heh), any subsequent Gemfile changes (to gems other than Bundler) get picked up at the start of the build… and we’re cruisin’

Have another solution? Please let us know in the comments.

  1. Tom Ward says:

    I’ve taken to vendoring the bundler too, but to get around the chicken and egg problem, I’m not using it to manage itself. I’ve written a simple rails template to set up a bundled project, which shows what I mean a little better:

  2. Corey Innis says:

    @Tom – Thanks for the response and the URL.

    Separately, a point of clarification (hopefully): A Pivot emailed to suggest that the “gem bundle” command should work fine without this Bundler bundling step, since Bundler does not affect the GEM_PATH for “other” applications. Keep in mind that we’re running `sh “gem bundle”` within a Rake task, so the command is in fact executed *within the context of* our application. I do agree that this is “probably not a good idea”, but it’s the best solution I’ve got so far.

    Keep the suggestions coming.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *