If gems are configured in config/environments/test.rb and "rake gems:build" is run in the production environment, the gems configured for the test environment are built. This forces the production machine to have the necessary libraries installed to build all gems used for testing. This patch updates "rake gems:build" to only build gems configured for the current Rails.env. http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1793-make-rake-gemsbuild-respect-railsenv --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
+1 On Fri, Jan 23, 2009 at 7:17 PM, Mark Van Holstyn <mvanholstyn@gmail.com> wrote:> > If gems are configured in config/environments/test.rb and "rake > gems:build" is run in the production environment, the gems configured > for the test environment are built. This forces the production machine > to have the necessary libraries installed to build all gems used for > testing. > > This patch updates "rake gems:build" to only build gems configured for > the current Rails.env. > > http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1793-make-rake-gemsbuild-respect-railsenv > > >--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
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. --josh On Jan 23, 2009, at 1:17 PM, Mark Van Holstyn wrote:> If gems are configured in config/environments/test.rb and "rake > gems:build" is run in the production environment, the gems configured > for the test environment are built. This forces the production machine > to have the necessary libraries installed to build all gems used for > testing. > > This patch updates "rake gems:build" to only build gems configured for > the current Rails.env. > > http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1793-make-rake-gemsbuild-respect-railsenv-- Josh Susser http://blog.hasmanythrough.com Golden Gate Ruby Conf :: April 17-18 :: http://gogaruco.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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
I recently encountered this circular dependency but I''m not a fan of
by passing the environment and more importantly the preinitializer
which my app makes heavy use of. The only problem I ran into was the
Rails::Initializer#prepare_dispatcher method that caused my
ApplicationController and/or ApplicationHelper to bomb on inclusion of
things like HoptoadNotifier::Catcher.
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
On Jan 25, 2009, at 11:08 AM, Josh Susser 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.
>
> --josh
>
>
> On Jan 23, 2009, at 1:17 PM, Mark Van Holstyn wrote:
>> If gems are configured in config/environments/test.rb and "rake
>> gems:build" is run in the production environment, the gems
configured
>> for the test environment are built. This forces the production
>> machine
>> to have the necessary libraries installed to build all gems used for
>> testing.
>>
>> This patch updates "rake gems:build" to only build gems
configured
>> for
>> the current Rails.env.
>>
>>
http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1793-make-rake-gemsbuild-respect-railsenv
>
> --
> Josh Susser
> http://blog.hasmanythrough.com
> Golden Gate Ruby Conf :: April 17-18 :: http://gogaruco.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 rubyonrails-core@googlegroups.com
> To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
> -~----------~----~----~----~------~----~------~--~---
>
On Sun, Jan 25, 2009 at 9:08 AM, Josh Susser <josh@hasmanythrough.com> 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 --~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
On Sun, Jan 25, 2009 at 5:39 PM, Chad Woolley <thewoolleyman@gmail.com> wrote:> > On Sun, Jan 25, 2009 at 9:08 AM, Josh Susser <josh@hasmanythrough.com> 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
+1 for this; I was very excited when rake gems came, but now I find myself never using it because of these problems. For instance, when I download an app I want to set it up -- can''t do rake db:schema:load because of missing dependency and I can''t do rake gems:install because of missing database schema. On Mon, Jan 26, 2009 at 23:32, Rob Sanheim <rsanheim@gmail.com> wrote:> > +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.--~--~---------~--~----~------------~-------~--~----~ 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 rubyonrails-core@googlegroups.com To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---