Rails::GemDependency#load prevents missing gems from aborting application initialization: fxn@feynman:~/tmp/test_gem$ script/runner ''p 1'' These gems that this application depends on are missing: - foo Run "rake gems:install" to install them. 1 Which is the rationale? Why would you want the initialization to go on in spite of missing gems? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Ah, let me add that application initializers and other bits are skipped altogether: def load_application_initializers if @gems_dependencies_loaded ... end end so the application is definitely up in a (generally) broken state. But there''s such an clear care with those rescues and flags that I guess there''s going to be a reason for the current implementation. --~--~---------~--~----~------------~-------~--~----~ 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 issue was raised before: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/bd1ea7763627ed0d Are your questions answered in that thread? On Sat, Sep 20, 2008 at 18:21, Xavier Noria <fxn@hashref.com> wrote:> > Ah, let me add that application initializers and other bits are > skipped altogether: > > def load_application_initializers > if @gems_dependencies_loaded > ... > end > end > > so the application is definitely up in a (generally) broken state. > > But there''s such an clear care with those rescues and flags that I > guess there''s going to be a reason for the current implementation. > > > >--~--~---------~--~----~------------~-------~--~----~ 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, Sep 21, 2008 at 3:04 AM, Mislav Marohnić <mislav.marohnic@gmail.com> wrote:> This issue was raised > before: http://groups.google.com/group/rubyonrails-core/browse_thread/thread/bd1ea7763627ed0d > Are your questions answered in that thread?Hey thank you Mislav I missed that thread. It is not clear to me that the rationale is explained there, but at least I see there are people that have a notion of "optional dependency" in which this behaviour might make sense for them. I am for sure +1 on failing hard and handling your occasional optional library with Ruby code anyway. --~--~---------~--~----~------------~-------~--~----~ 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 Sat, Sep 20, 2008 at 10:29 PM, Xavier Noria <fxn@hashref.com> wrote:> I am for sure +1 on failing hard and handling your occasional optional > library with Ruby code anyway.+1 for failing hard. If your application is smart enough to fall back on an alternative behavior, rescue the exception and continue. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
If the optional gem is common, why not a config.optional_gem method? Covers all bases explicitly and succinctly. On Sat, Sep 20, 2008 at 10:58 PM, Damian Janowski <damian.janowski@gmail.com> wrote:> > On Sat, Sep 20, 2008 at 10:29 PM, Xavier Noria <fxn@hashref.com> wrote: > > I am for sure +1 on failing hard and handling your occasional optional > > library with Ruby code anyway. > > +1 for failing hard. If your application is smart enough to fall back > on an alternative behavior, rescue the exception and continue. > > > >--~--~---------~--~----~------------~-------~--~----~ 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 Sat, Sep 20, 2008 at 8:46 PM, Blake Watters <blake@near-time.com> wrote:> If the optional gem is common, why not a config.optional_gem method? Covers > all bases explicitly and succinctly.This was discussed in a recent thread. Rubygems already provides a way to flag development gems. Aside from that, any determiniation of "optional" is developer-, platform- or environment- specific, and is best handled with custom code in the environment file(s). In any of these cases, you would need some custom code anyway to determine whether the non-development "optional" dependency is actually required or not (inclusion in a specific environment file rather than environment.rb, platform check, env var check, etc). So, if you need custom code anyway, just write your own conditional to not even execute the optional config.gem call. No need for a separate method. -- 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 -~----------~----~----~----~------~----~------~--~---