On Feb 17, 2011, at 23:04 , James Tucker wrote: > If I remember the code order correctly, it wouldn't solve the rack, thin and > sinatra issue, or the datamapper issues. Those would still conflict using > lazy activation, because the libraries are actually Kernel#require'd prior to > the conflict arising. An ahead of time resolution can still solve those > cases. I think we did cover one of those examples in discussions at Rubyconf, > I'm not sure if we made a test. A specific example is available in the 'gem > lock' discussion on this ML.
$ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ruby ~/tmp/gems/bin/thin start >> Using rails adapter Missing the Rails 2.3.5 gem. Please `gem install -v=2.3.5 rails`, update your RAILS_GEM_VERSION setting in config/environment.rb for the Rails version you do have installed, or comment out RAILS_GEM_VERSION to use the latest version installed. versus: $ GEM_HOME=~/tmp/gems GEM_PATH=~/tmp/gems ruby -I ~/Work/git/rubygems/lib ~/tmp/gems/bin/thin start >> Using rails adapter >> Thin web server (v1.2.5 codename This Is Not A Web Server) >> Maximum connections set to 1024 >> Listening on 0.0.0.0:3000, CTRL+C to stop _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
