From: Hugh Sasse <hgs@...>
Date: 2005-10-03T21:39:10+09:00
Subject: Re: why can't Ruby load .gem files directly?

On Mon, 3 Oct 2005, Joshua Haberman wrote:

>
> On Oct 2, 2005, at 5:06 PM, Austin Ziegler wrote:
>
>> On 10/2/05, Joshua Haberman <joshua@reverberate.org> wrote:
>> 
>>> There are many cases where "gem install" is not suitable, but "tar
>>> xf" is.
>>> 
>> 
>> I'd love to know one, for a .gem. Seriously.
>
> - you want to install Ruby and a bunch of gems onto a software partition that 
> will be mounted read-only from tens or hundreds of nodes.

nodes == machines?  I don't think this is a problem if the
mountpoint on each machine is the same, so the paths come out the
same in the end.  In the case where the mountpoints are different,
I'm not sure what might be provided to help, because the possible
variations seem very large.
>
> - you want to create a rescue disk image that will be mounted read-only.
>
> - you want to create an image that will be installed onto an embedded 
> device's ROM

I'm not sure about those two.  I have attempted neither.
>
> The philosophy inherent in "gem install" -- that I am going to "install" the 
> gem on any machine that will ever run it, and I will have write access to do 
> so -- is narrow and brittle.

I think you'll always need write access to *do* the installation, but
you won't need it afterwards to use the installation.  But in the
case of shared (mounted) directories, you only install on the server
and it just works on the client.  That's how it works for us on our
Sun network.  Have you had problems with this model?  If we know
what they are we may be able to take that into account.

>
>> There's absolutely *no*
>> advantage to untarring a gem, and (IMO) serious disadvantages. Why would
>> you even think about forgoing what RubyGems offers?
>
> Until you understand the answer to this question, you will not understand the 
> opposition to your current plans.
>
> The answer is: the things that RubyGems offers are not appropriate in every 
> circumstance.  It is great to make things easy for the common case, but 
> you've got to make them possible for the unusual case as well.  Ruby's 
> packaging system needs to be a tool that skilled programmers can use to fit 
> their needs, not a policy layer that demands you do things "the gem way."

Yes, that is why we are trying to gather requirements to supplement
DATADIR and  `gem unpack thisgem.gem`
>
> I'm not opposed to the existence of "gem install/uninstall."  I am opposed to 
> any attempt to force people to use gem install/uninstall if it is not 
> appropriate for their situation.

And much of the discussion is aimed at adding the right hooks to (a)
make it correct for more situations and (b) supply the facilities
needed for the remaining cases.
>
> Josh

         Thank you,
         Hugh