--josh
--
Josh Susser
http://blog.hasmanythrough.com
Golden Gate Ruby Conf :: April 17-18 :: http://gogaruco.com
This could be a disconnect with plugin/gem development that might
involve a better way... ie, having the lib send the include when the
plugin/gem is loaded. That said, I just took the short term bailout
and used code like this in those files.
unless $rails_gem_installer
include HoptoadNotifier::Catcher
end
I'd love to know if things like #prepare_dispatcher should use
conditional `if gems_dependencies_loaded` code like many others do in
that class and or better solutions to the problem since my fix above
only helps if you are in any of the gem namespaced rake tasks.
- Ken
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google
> Groups "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonra...@googlegroups.com
> To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
Exactly. I expounded upon this at mind-numbing length in this ticket:
Summary:
1. Bottom line, the config.gems logic should be completely decoupled
from environment, and invokable from preinitializer.rb. Anything else
will be subject to circular dependencies.
2. Obligatory mention of GemInstaller, which does exactly this, very
successfully, for many production apps, and predates config.gems (and
is the reason I wrote the preinitializer.rb patch)
Thanks
-- Chad
+1 for Chad's note about config.gems. I see a lot of broken builds
"cross my desk" at RunCodeRun, and I can attest to how many are due to
this very circular dependency. (the other is the :db => :environment
one that has been fixed). Decoupling config.gems will do a ton to
make dependency resolution much easier.
- Rob