After looking into this more (tracing the call chains all the way
through rubygems and rails), it's clear to me that this is actually
the expected behavior.
In short, unpacked gems cannot be loaded using Kernel#gem. It's just
the way it is. If you want to load an unpacked gem, you have to load
it using config.gem (which is Rails::Configuration#gem) in
The obvious problem with this is when one of your unpacked gems has a
dependency on another gem, and thus calls Kernel#gem directly. This
is the case in my situation. So I config.gem the gem I want. But
when the gem is loaded, it in turn calls Kernel#gem, which produces an
Has anyone else had a problem with this? Does anyone have a
workaround that's better than patching the gem(s) causing the problem?
To me, this seems like something that could use attention in rails
core. I am happy to try to work on this, but someone else may be more
qualified in terms of experience with the code base (this would be my
first foray into rails core development).
I think there are a couple of options. One would be to replace
Kernel#gem with a method that can test for gems loaded via config.gem;
if no gems are found, then it defers to the original Kernel#gem.
Another option would be to modify Rails::GemDependency#add_load_paths
to tell rubygems that it has loaded the gem in question. This is
done, for example, when you have frozen rails into vendor/rails (see
At this point I'm rambling. I think I'm going to go ahead and tackle
this, using the latter strategy for now. I'll write back if I find