Question

Can you deploy a Rails3 app using Bundler’s Gemfile WITHOUT running bundle install… i.e. just by copying a rails project directory to the appropriate dir within Apache/Passenger?

So, we have a legacy environment that was designed for internal projects during the Ruby1.8.6/Rails2 timeframe and it depends on copying your local rails directory to a network mount under Apache/Passenger. While this deployment model worked fine for Rails2 (with frozen gems, etc.), it breaks in many painful ways for Rails3 with Bundler.

Specifically, I’m seeing gem dependency errors for gems in :test and :development groups even when deploying to :production. I found the following SO post helpful at first:

• bundler incorrectly trying to install "development" and "test" group gems in production

So I executed bundle install --without test development on my local and then tried to manually copy .bundle/config from my directory to the network dir, but that didn’t work. Bundler still tried to load the excluded gems.

This is painful for us because we don’t have admin privileges to install gems on these servers (i.e. we aren’t allowed to ever run bundle install in any form). Likewise, the admins do not want to be bothered with deploying our apps every 5 mins since this is an internal prototyping site and not an external production site. They also don’t want to run bundle install because they want tight control of which gems are deployed across all applications — for example, some apps are still Rails2 based and don’t use Bundler yet, so they may break if the wrong gem is installed.

Is there any way to use Bundler in a passive/rsync way, or should we just redesign our environment to let developers run bundle install via capistrano or some such?

Help?

Thanks!

---

UPDATE: 1/18/2012: After investigating the reason for the :test and :development group errors some more, I discovered that Phusion Passenger actually executes Bundle.setup() before the Rails app gets a chance to in boot.rb. Without any arguments, setup() checks all gem dependencies, which means if it doesn’t find a gem on the server, it will blow up in Passenger before it even gets a chance to load Rails.

This particular ‘bug’ can only happen if you deploy via rsync or copy instead of running bundle install --without test:development on the target server. The majority of Rails3 apps are deployed with Capistrano, which does this step for you, and as such never encounter this particular edge case.

So I’m afraid the only way to get ‘groups’ to work correctly in your gem file is to use bundle install as intended. This means we should change our deployment process!

Answer 1

Some other rails devs and I were discussing how to effectively freeze gems in Rails 3 and we worked out this solution. This is along the lines of what @asymmetric proposed, but different in some key ways. As I later discovered from the gemfile man page, this approach also suffers from the same limitation that @indirect warned of with bundle install --deployment, in that your gems must either be pure ruby (no native compilation), or these steps must be done on an identical architecture to your stage and prod servers.

Ok, now that we have the preliminaries out of the way, let’s see about “freezing” some gems into Rails 3…

First, start with a clean environment:

$ rvm gemset use fresh
$ rvm gemset empty fresh
$ gem install rails
$ rails new strawman
$ cd strawman/

Next, install the gem you want to use:

$ gem install condi

Next, create a vendor/gems directory and unpack the gem within it:

$ mkdir vendor/gems
$ cd vendor/gems
$ gem unpack condi
Unpacked gem: '/tmp/strawman/vendor/gems/condi-0.0.6'

OPTIONAL:

If your gem doesn’t have a .gemspec file with it (i.e. the spec is part of the contained Rakefile build), Bundler may not be able to load it correctly with the :path statement. In this case, you have to output the gemspec from the gem file using:

$ gem specification /tmp/condi-0.0.6.gem > condi-0.0.6/condi.gemspec

Or if you already have the gem installed locally, you can:

$ gem specification condi -v=0.0.6 > condi-0.0.6/condi.gemspec

Now, update the Gemfile with the line:

gem 'condi', '0.0.6', :path => 'vendor/gems/condi-0.0.6'

NOTE: “Unlike :git, bundler does not compile C extensions for gems specified as paths.” [man gemfile] So this only works for pure ruby gems without native extensions! Be warned!

Next, uninstall the gem from your gemset:

$ gem uninstall condi
Successfully uninstalled condi-0.0.6

And returning to the rails root environment, try to run the rails console:

$ cd ../..
$ rails c
Loading development environment (Rails 3.1.3)
1.9.3-p0 :001 > 

Success!! Your pure ruby gem is now effectively frozen in a Rails 3 app.