On Oct 2, 2005, at 8:55 PM, Austin Ziegler wrote:

> On 10/2/05, Joshua Haberman <joshua / reverberate.org> wrote:
>
>> On Oct 2, 2005, at 5:06 PM, Austin Ziegler wrote:
>>
>>> On 10/2/05, Joshua Haberman <joshua / reverberate.org> wrote:
>>>
>>>> On Oct 2, 2005, at 4:00 PM, Austin Ziegler wrote:
>>>>
>>>>> I also believe that the *right* way for package management systems
>>>>> to work with RubyGems is to *use* RubyGems and the facilities it
>>>>> offers (or will offer) to install gems.
>>>>>
>>>> Why?
>>>>
>>> Because RubyGems offers several features -- package and API version
>>> management, easy package install/uninstall, etc.
>>>
>> API version management is great.  But you don't need to use "gem
>> install/uninstall" to reap the benefits of it.
>>
>
> Actually, yes, in fact, you *do*. You need something integrated  
> into the
> language that allows you to have multiple versions of a library
> installed that does not also moronically lock you into a single  
> version
> by default (e.g., the sometimes suggested 'require "foo-1.0"'  
> concept).

Integrated into the *language*, I completely agree.

What I said is that there's no need to require gems to be installed  
by the "gem" command to get this benefit.  The RubyGems runtime can  
sort this all out at runtime.

>> The package install/uninstall are only easy if your system setup
>> matches the assumptions implicit in the design of the "gem" command.
>>
>
> This is a completely incorrect statement. I'll leave it to the  
> reader to
> actually *think* the concept through.

This would be a more substantive conversation if you would actually  
make your points instead of leaving them unspoken.

>>>> 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.
>>
>
> This has nothing to do with RubyGems, and can (in fact) be managed by
> RubyGems as it stands. This point -- as well as your other two -- are
> completely irrelevant to RubyGems itself. Suggesting otherwise really
> indicates that you *do not* understand what RubyGems offers in the
> least.

Again, let's actually state what these things are (that RubyGems  
offers), instead of leaving it unspoken.  If I'm wrong here, please  
correct me:

RubyGems offers:

1.  a method for creating, querying, and fetching from remote gem  
repositories

2.  dependency tracking between gems, which allows you to fetch a gem  
and all its dependencies, and check dependencies at install time.

3.  an install step, which can generate application stubs, generate  
documentation, and run unit tests, and ultimately extracts files in  
such a way that the gem is usable by the RubyGems runtime.

4.  a runtime component which can load a gem, optionally based on its  
version number.

I like (4) a lot.  I see (1) and (2) as useful when you want them,  
but I appreciate that you can bypass them by using local operations.   
It's just (3) that concerns me.  Here's why.  Say I do "gem install  
foo.gem --install-dir ~/my-install-dir".  Here are my concerns:

1.  it's not clear to me that gems in my-install-dir will function  
properly if my-install-dir is read-only after the installation.

2.  it's not clear to me whether I can copy my-install-dir to another  
machine, point my GEM_PATH there, and have everything "just  
work"  (Jim gave me a suggestion for achieving this, but it involved  
basically circumventing the "gem" command, implying that this isn't a  
supported use case using the standard software).

>> 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.
>>
>
> It's never *not* appropriate. Just lock down the gem command if you
> don't want average users using it. But, then, of course, you can't  
> allow
> *local* gem installs that way, either, and RubyGems explicitly  
> supports
> that. Which means that you're left with locking down the shared  
> items on
> a read-only environment and letting Ruby's standard mechanisms for
> working with the operating system raise exceptions as appropriate.

I think you've misunderstood my use case: it has nothing to do with  
whether "average" users can use the gem command.  It has to do with  
whether I can use gem-packaged Ruby software without having to run  
"gem" on the target machine.

> Don't throw up roadblocks because you don't
> understand what is actually offered -- and don't pretend that  
> Debian or
> FreeBSD's solution is "All That."

The question is not whether Debian's or FreeBSD's packaging systems  
are "all that."  The question is whether you will let them do things  
their own way, or whether you will try to force your solution on them  
because you think you've found the One True Way.

Josh