> If you are writing a program for home or work use, where you control
the
> runtime environment, then this is a reasonable approach:
>  * in the "base file" of your project, require 'rubygems'
>  * in other project files, require the "base file"
>  * now 'require_gem' is available wherever you like

> For instance, my work project is called 'dmv1'.  Nevermind what that
> means.  So I have 'lib/dmv1.rb' which is the "base file", which
defines
> some modules, constants, etc., that are used across the board. 
> 'lib/dmv1/**/*.rb' all "require 'dmv1'" and build on those modules.
So
> without any real effort -- just some thought in project structure --
> require_gem is available everywhere.

What you describe doesn't quite follow the Ruby 'require' process.
'require' isn't the same as #include of java's import: you do not need
to require a library from every file that uses it. Once you have
require'd a file everything in it has already been brought in to the
interpreter.

For an app/lib type of work you describe, where users will always call
through the "base file", you can just put all your requires there (or in
one file called from the base). This has the advantage that you can deal
with all external libraries and their versions in one place.