Satya's blog - 2011/03/

class Rails::Boot
  def run
    load_initializer
    Rails::Initializer.class_eval do
      def load_gems
        @bundler_loaded ||= Bundler.require :default, Rails.env
      end
    end
    Rails::Initializer.run(:set_load_path)
  end
end

begin
  require "rubygems"
  require "bundler"
rescue LoadError
  raise "Could not load the bundler gem. Install it with `gem install bundler`."
end

if Gem::Version.new(Bundler::VERSION) <= Gem::Version.new("0.9.24")
  raise RuntimeError, "Your bundler version is too old for Rails 2.3." +
   "Run `gem install bundler` to upgrade."
end

begin
  # Set up load paths for all bundled gems
  ENV["BUNDLE_GEMFILE"] = File.expand_path("../../Gemfile", __FILE__)
  Bundler.setup
rescue Bundler::GemNotFound
  raise RuntimeError, "Bundler couldn't find some gems." +
    "Did you run `bundle install`?"
end

source :gemcutter
gem "rails", "~> 2.3.5"
gem "sqlite3-ruby", :require => "sqlite3"

(reproducing the instructions here mostly for myself.)

That Gemfile goes in your application's rails root, i.e. the parent of app/ and config/. Okay, fine. So I set up an application that way, and it worked. I then commented out the 2.3.5 and it continued working. So I set up another application the same way and it failed. After 2 hours of headbanging, I realised that the Gemfile.lock was being used instead. Symptom: rails fails to start with:

    no such file to load -- initializer

Now if you start it at least once with the 2.3.5 NOT commented out, it'll keep working even after you do comment it out. Might be a weird permissions interaction, though.

The rant here is, .lock files are a *nix convention for, well, locking. As in concurrency control. Transient files. This Gemfile.lock isn't that kind of file. And it needs to be writable by the web server, unlike all the other files in your rails root. Ugh.