From: Richard Kilmer <rich@...>
Date: 2005-03-04T14:11:16+09:00
Subject: Re: ruby gems, and the require problem (was Re: RAA Status & b)




On 3/3/05 11:53 PM, "Sam Roberts" <sroberts@uniserve.com> wrote:

> Would be a work-around, and I'm afraid it is oriented at the installer
> of gems, so speaking as a library packager, it doesn't solve my
> problems.
> 
> The command line tools I make that use my libraries, they do a
> "require", only. If "deployment" doesn't occur, and its an optional
> second step, the gem users who don't do the
> 
>   gem deploy net-mdns
> 
> are going to be coming back to me and asking why my mdns.rb script won't
> find net/mdns. IMHO, if deploy doesn't always occur, it still leaves me
> with having to maintain different versions of scripts and libraries -
> gem using, and non-gem using.

No...they need to get your library:

gem install net-mdns

And if they have RUBYOPT=rubygems

Their code looks like:

require 'net/mdns'

If they don't have the RUBYOPT, or don't want it, they can do:

gem deploy net-mdns

Or even more concise to download and deploy:

gem install net-mdns --deploy

With the --deploy option able to be set in the .gemrc or something.

The thing is you assume they install your net-mdns in site_ruby which may
not be what folks want.  You need to have two steps...get the
library...deploy it in some directory that is in the $: path.  This is the
same thing that setup.rb does (deploy into a dir...site_ruby default) Having
the RUBYOPT makes the deployment happen kinda magically at runtime as you
need it.  The extra deploy step lets you do it without the magic runtime
require hack stuff.  But the ability to target where to deploy (like --dir
my_test_dir) makes it rather powerful in that you can have lots of site_ruby
like dirs that hold sets of deployed gem libraries (.rb/.so) and $:.unshift
them for testing, etc.

Anyway, its a thought.

-rich