rails:freeze:edge task is broken [updating to 2.0]

rubyonrails-core
1

Thanks, Glenn.

To everyone: I’ve been wanting to bring this issue up for a long time now, but always keep forgetting. Everyone knows by now that AWS has been replaced by ActiveResource. This change in framework requirements broke the freeze:edge task for reasons already discussed. The questions I want to bring up are:

  1. Are we going to “fix” this in Rails 2.0 Initializer (ie. make it not whine about missing ARes)?
  2. If the Initializer is not going to change, should we be telling users that the preferred way of fixing this issue is running the freeze task twice?
  3. Are we going to do something about this for the future (however unlikely changing the frameworks again might be)? It’s a shame that this error message is so daunting and misleading. I feel sorry for all those people already wasting hours trying to figure out what is wrong.
2

Are we going to "fix" this in Rails 2.0 Initializer (ie. make it not whine about missing ARes)?

This seems reasonable, it will at least stop hurting people when we next release from trunk.

If the Initializer is not going to change, should we be telling users that the preferred way of fixing this issue is running the freeze task twice?

Running a freeze from 1.2.4 will get the right components. Unfortunately 2.0PR1 landed before 1.2.4 did.

Are we going to do something about this for the future (however unlikely changing the frameworks again might be)?It's a shame that this error message is so daunting and misleading. I feel sorry for all those people already wasting hours trying to figure out what is wrong.

If we'd pushed 1.2.4 before 2.0pr1 then user's would have had a safe upgrade which pointed out a few of these things. I think that's a safe approach for the future, unless I'm missing something.

3

The biggest problem is the misleading error message and stack trace. I’ve investigated, and it turns out Mongrel swallows LoadErrors raised in Rails::Initializer. (Don’t ask me why.) After it swallows the error, something happens that pushes the Rails 1.2.3 gem into load paths, “commands/servers/mongrel.rb” gets re-loaded from the wrong place and the whole thing crashes miserably.

Koz, please see my patch: http://dev.rubyonrails.org/attachment/ticket/9743/require-frameworks.diff

It doesn’t make Rails tolerate LoadErrors in require_frameworks. Without ARes, starting Mongrel will still fail, but at least with this patch users will get the proper error message and stack trace about not being able to load ARes.