On 12/26/2003 7:23 PM, Richard Kilmer wrote:
> 
> 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.

How well will this method scale? If I'm understanding you correctly, the 
search path will grow for each module installed. This means the more 
modules you install the longer it will take to search for modules to 
load. Or did you mean something different when you said "managing the 
LOAD_PATH"?

Regards,
Randy.