On Dec 26, 2003, at 5:01 PM, Martin DeMello wrote:

> Richard Kilmer <rich / infoether.com> wrote:
>> library system does not.  I mean, as a short term solution we could
>> create a Gem that picks up the Ruby version and you just do:
>>
>> require_gem 'ruby', '> 1.8'
>>
>> or something...of course that .gemspec would not actually modify the
>> LOAD_PATH as other Gems do, because Ruby's libraries are already in
>> the LOAD_PATH.  If you then place a dependency on ruby 1.8 (or 1.8.1,
>> etc) you would be guaranteed to have REXML, WEBrick, XMLRPC4R, etc.
>>
>> Hm...now that I think of it, that is pretty sweet.  If folks thinks
>> this is good, it could be done quite quickly.
>
> Another idea is to have a lightweight gem manifest, downloadable as a
> separate entity, that would check for all the files in the gem, and if
> you have them all, spring the gem into existence. That way, if you
> manually install a package, you can use its manifest to make it look
> like you installed it from a gem all along.

The issue is that what a Gem IS is a directory of Ruby files, along with
metadata about that directory.  If you just have an arbitrary directory
of Ruby files (like in site_ruby) you would have to create metadata for
that.  The main benefit of a Gem is to allow you to add/remove libraries
easily (which cannot be done now because they are all added to the same
dir).  It does this by managing the LOAD_PATH.  A side benefit is the
ability to have versions of Gems, although only one version of a Gem
can be loaded per Ruby interpreter.

Gems is not a replacement for 'require', and it is require with a
LoadError that aids you in knowing whether a library is installed
or not.

-rich