What's the best strategy for native gems?

[Brian Del Vecchio]

I'm having issues with native gems on deployment, using config.gem in
Rails 2.3.4.

I notice that rubber is doing some helpful things in some cases, but
not when I have committed vendor/gems after 'rake gems:build'.

Should I not be committing the compiled gems? Should I git ignore the
whole vendor/gems directory and let rubber deal with them at deploy
time?

[Matthew Conway]

The problem with the rails config.gem mechanism is that its very easy
to get into a catch-22 situation - can't run the task to install the
gems because your environment needs the gems loaded to run! This may
not be the problem in your case, but I know others have reported that
they prefer to use a gem dependency mechanism not baked into rails
(gem bundler?)

Personally, I prefer to just enumerate all the gems I use in my
rubber.yml because this has no dependency on loading up my projects
environment. Its also what I'm used to as I wrote it before
config.gem was on the scene :) Also, it gives you the ability to only
install certain gems on specific roles/host. Rubygems will then just
build native gems as needed, and correctly handles the case when you
need a 64 vs 32bit compile (e.g. using a large/x-large instance) - I'm
not sure if gems:build/vendors/gems handles this.

I guess I could make rubber more intelligent and have it parse
environment.rb to extract out the config.gem lines rather than relying
on the gems:install task to install them. I currently duplicate the
gems I have in both config.gems and rubber.yml so that they get
"required" correctly and so that RubyMine knows about them, but I
never actually use the gems:install task.

Matt

[Brian Del Vecchio]

I've had a particularly hard time with nokogiri, which would not load successfully when installed as a system gem with or with a config.gem statement. 

So this is a Big Hammer solution to the problem:

after "deploy:update_code", "rubber:rebuild_gems" if Rubber::Util.is_rails?

namespace :rubber do

  desc <<-DESC

    rebuild the ruby gems in the newly installed tree.

  DESC

  task :rebuild_gems do

    run "cd #{current_path} && RAILS_ENV=#{RUBBER_ENV} rake gems:build:force"

  end

end

This rebuilds the gems after the code is in place but before db:migrate, which was running before rubber's existing (and inadequate for native gems) gems:install.

Brian Del Vecchio  |  b...@hybernaut.com  |  617-899-0798  |  @hybernaut

[Brian Del Vecchio]

NOTE: this is totally wrong due to the use of #{current_location}. 

I'm not done yet.

Brian Del Vecchio  |  b...@hybernaut.com  |  617-899-0798  |  @hybernaut