Why does rack have to be installed as a gem?

At best, you could have Rack in vendor/gems - but as discussed here:

http://groups.google.com/group/rubyonrails-core/browse_thread/threa...

That's going to potentially lead to problems in some environments.

Not sure if that was intentional, I did a tonne of changes before
coming home tonight and have lost track.

Matt's the guy for 2-3-stable's gem stuff, so if he thinks it's viable
for 2.3 then cool, otherwise happy to bump to 3.0.

I tend to agree with Koz on the wontfix (for 2.3) - the 2.3 gem loader isn't capable of supporting this well. See this discussion on the core list for more detail.

@matt sounds good. We should have this fully working on edge in the next week or two -- it should be natively supported once we wire up the git-as-gem support into the bundler.

I'm still in the dark as to why rack is the only library that rails 2.3 requires be installed as a gem, even if it's already included in my application.

Would it work to rescue the exception raised by rubygems if rack isn't installed as a gem?

Or is there a reason why rack has to be loaded as a gem? For my applications, I've been commenting out the "gem 'rack'" line and everything has been working fine.

@Joe Van Dyk:

Check the links from the rails-core list above; the issue is that the gem is loaded well before the Rails initializer stuff gets to run - if you're running from an installed gem version, it's already been activated by the time you get to the "gem 'rack'" line in action_controller.rb.

Also note the discussion of the behavior under Passenger; in summary, it's not currently practical to vendor Rack because it won't work consistently across deployment environments. You can try unpacking it in vendor/gems, but there's no guarantee it will work correctly everywhere.

Matt -- if the rack gem has already been loaded by the time the code gets to "gem 'rack'", then why have it there?

There's a key difference for gems between 'loaded' and 'activated'. 'Loaded' is what most people think of - the gem has executed its initialization code and loaded its classes into memory; typically this is accomplished with require. 'Activated' is more complicated. A gem is 'activated' after you call "gem 'foobar'", but all that means is that its spec has been loaded and the declared load paths added to the Ruby load path. 'gem "foobar"' does one other thing: if it's passed a version string and the gem is already activated, it verifies that the activated gem satisfies the version requirement and fails if it doesn't. So the "gem 'rack', '~> 1.0.0'" line serves to both activate Rack and verify that the version is 1.0.x, avoiding weird errors down the line if it's not.