On 12/26/2003 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.
> 

IMO it would be best to have some kind of database that stores module 
name, version with a md5 checksum of the files. Then if you failed to 
find a gem, you could fall back on a search of your lib and site_lib 
directories for the module, compare checksums to determine version, and 
then validate the requirement. It's ugly, but it's temporary. It's much, 
much better than depending on the user; my experience in the perl 
community has taught me that most users don't have a clue what modules 
they have installed, what versions they have, or how determine any of 
the aforesaid. If you do depend on the user, you should also be prepared 
for users complaining they accidently entered the wrong info, and now 
they don't know how to fix it, etc. Either way it will likely be a PIA 
until gems fully mature and take over as _THE_ means of distributing 
ruby modules.

Regards,
Randy.