Satya's blog - Gemfile.lock in Rails 3
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 end2. put this in config/preinitializer.rb: 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`?" end3. This'll do for your Gemfile: 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. |
|