Wes G. wrote:
So I think the question still stands. Is require_gem only do the
The require_gem does two basic functions:
(1) Activates a gem with an appropriate version number (see below for
more on “activate”)
(2) Auto requires the autorequire file if the gem has specified one.
After much experience with gems, the RubyGems team has come to the
conclusion that the autorequire step causes more trouble than its worth.
The require_gem command will be probably be deprecated in the future and
be replaced with a command that only does the activation step.
(‘activate_gem’ will probably be then name of this new command, although
no promises there).
Require_gem is only needed if you wish to assert which versions of a gem
you are willing to accept. If you don’t care, it is better to not use
What does it mean to “activate” a Gem?
Gems are not stored in a place where Ruby can normally find them. To
activate a gem means to manipulate Ruby’s search path so that the gem
may be found by a require statement. Only one version of any given gem
can be activated at a time.
Today, Gems monitors all require requests given to Ruby. If a require
fails to load a file, then Gems will check its repository to see if
there is a file that satisfies the require statement. If so, RubyGems
will activate the latest version of the gem that provides that file and
will retry the require.
Since RubyGems now automatically handles normal require statements
semi-intelligently, the autorequire feature of the original require_gem
is more of a hinderence than a help.
– Jim W.
 For example, if a gem has an autorequire file, then that autorequire
file will be loaded by the activation step. If a user does a normal
“require ‘xyz’” that triggers an activation, when the require is retried
the file will be already ‘autorequired’. There’s is no harm in that
except that the result of the user’s require statement returns false
(since the file will autoloaded durning activate), and returning false
confuses a lot of people. I hope this footnote didn’t ramble too much.