EDIT: I had only figured out part of the problem. You can read more detailed explanation here.
I was finally able to solve bundler error on Spring. Yay me!
It all started when bundler began cleaning ENV[“RUBYLIB”] and the change was released with bundler 1.11.0. Spring failed to `require bundler/setup` cause it was depending on bundler leaving that RUBYLIB path uncleaned. That require wasn’t suppose to fall back to RUBYLIB path in the first place, it was suppose to find it in GEM_PATH. However, GEM_PATH was empty string when one chooses to change the default bundle install path for their app. I don’t know yet if that a desired behavior, I guess I will look into it.
I am glad I took the time to figure it out. Now, I have much better understanding of how the ENV and $LOAD_PATHS work. Hey, did you know that ENV.delete(“key”) returns the value of deleted key? Also, the subtle difference between `dup` and `clone`? This example from ruby doc sums it well:
class Klass attr_accessor :str end module Foo def foo; 'foo'; end end s1 = Klass.new #=> #<Klass:0x401b3a38> s1.extend(Foo) #=> #<Klass:0x401b3a38> s1.foo #=> "foo" s2 = s1.clone #=> #<Klass:0x401b3a38> s2.foo #=> "foo" s3 = s1.dup #=> #<Klass:0x401b3a38> s3.foo #=> NoMethodError: undefined method `foo' for #<Klass:0x401b3a38>
You should check out RailsConf 2015 — Breaking Down the Barrier: Demystifying Contributing to Rails from Eileen Uchitelle. She explains use of `caller` and `tracepoint`. I found them really useful while understanding the flow of control in Spring. She also demonstrates use of `git bisect`. Turns out, it is not as intimidating as I though it would be.