> Everybody keeps telling me Bundler is awesome, but to tell you the truth
> I never had any problems with gem dependencies in the past. It wasn't like
> unpacking gems into an app and using a few select gems on the server is
> actually difficult.

There are definitely some people (like you) with that experience. There are also a lot of people with the opposite experience. Unfortunately, dependency issues are silent killers--they pop up out of nowhere and kill you for days while you try to understand what gem that happened to exist on production took down your app. This is no exaggeration; Ruby forums are littered with the corpses of people who thought everything was fine until an errant gem install rack on a developer machine or on production inadvertently took down their app.

> Furthermore: now with Bundler my deployments *are* actually more
> difficult all of a sudden. Even though I have the rspec gem in the development
> "group" (why is this not named environment?)

People use groups for things other than environments. For instance, some people put all of their cucumber dependencies in a :cucumber group, but don't necessarily have a cucumber environment. In Rails, we made group == environment by default.

> when I deploy on production Bundler still wants to install it. Why oh why?
> No documentation will tell me.

If you do nothing but run `bundle install` on production, bundler will install all groups. The simplest way to deploy bundler, as documented at http://gembundler.com/deploying.html (and also on the front page of gembundler.com) is to put require "bundler/capistrano" in your capistrano file. This task defaults to skipping the development and test groups, and allows you to configure it to skip other groups if you wish. It also uses `bundle install --deployment`, which installs the gems to a local path in your application, dealing with a number of common issues involving passenger and unicorn.

> You seem to be using some magic to get this to work, but alas no actual
> light on this subject. Is there a black craft to this?

Engine Yard uses bundle install --deployment --without development test, which is the same thing that the bundler/capistrano task does for you.

> If you ask me, Bundler is like using a state of the art NASA kevlar sheet
> instead of a band-aid for a minor cut.

Fixed! Thanks for reporting that :)

Yeah. Use Post.all when you expect to get back an Array; use Post.scoped if you want a relation.

Good catch. Both typos are fixed :)

Then you believe incorrectly ;)

The benchmarks are located at http://github.com/wycats/rails-simple-benches and can be run by checking the repo out into the actionpack dir in Rails. It includes the full cost of a Rack request, without the network overhead (important, but not a cost that Rails is responsible for).

Ha. I think I probably would have pointed you to those same places. Rails 3 exposes a Railtie class that any plugin can subclass and have access to initialization, middleware, configuration, etc. We're still working on the right workflow for routing stuff (because there are multiple "correct" solutions), and we'll have stuff for you soon.

Yeah. Leftovers from the syntax highlighting fail. Looking into fixing it.

Should be fixed. I believe it also won't recur :)

Thanks for pointing it out. Seems to be a bug with our syntax highlighting. I'll see if I can get it taken care of :/

Plugins should individually pull in the parts of ActiveSupport that *they* need. You'll only need to pull in parts of ActiveSupport that you're explicitly using -- I agree that otherwise the idea would be untenable.