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
On Sun, Sep 21, 2008 at 3:04 AM, Mislav Marohnić
[EMAIL PROTECTED] 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
John, this is a _fantastic_ point. It's certainly true that there
would be no way to use the setter half of a private attr_accessor in
a regular Ruby object:
self.bar = 'baz' # violates private
bar = 'baz' # sets a local variable
Well, no, that would be silly. Private methods in
On Sat, Sep 20, 2008 at 10:29 PM, Xavier Noria [EMAIL PROTECTED] 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
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 [EMAIL PROTECTED]
wrote:
On Sat, Sep 20, 2008 at 10:29 PM, Xavier Noria [EMAIL PROTECTED] wrote:
I am for sure +1 on failing
On Sat, Sep 20, 2008 at 8:46 PM, Blake Watters [EMAIL PROTECTED] 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
