On Sun, Jan 25, 2009 at 5:39 PM, Chad Woolley <[email protected]> wrote: > > On Sun, Jan 25, 2009 at 9:08 AM, Josh Susser <[email protected]> wrote: >> >> This is a good improvement, but I dislike that building gems loads the >> environment at all. If something in your environment file uses a >> class defined in a gem, you get a circular dependency where you need >> the gem you're trying to build in order to build gems at all. Seems >> like the only way out of this is to move the config.gem stuff into a >> separate file that can be used during the environment booting/ >> initialization, or for building gems without the environment. > > Exactly. I expounded upon this at mind-numbing length in this ticket: > > http://rails.lighthouseapp.com/projects/8994/tickets/59-when-loading-a-plugin-via-rubygems-rake-tasks-aren-t-included > > 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 http://thinkrelevance.com http://runcoderun.com --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
