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).

> 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.

>>> 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.

> 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.

Then restrict the availability of the gem command. It's not *that* hard,
and suggesting otherwise is a cop out from someone who doesn't get it.

>> 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.

Until you understand why your question is not only nonsense, you will
not understand why I won't accept anything that isn't *centered* around
RubyGems. It's attitudes like yours that basically is leaving me with
"No Special Treatment For Debian Users With Special Needs." I have no
patience for this nonsense.

> 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."

That's not an answer; that's a cop-out.

> 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.

Indeed, most of the time, you want to do:

  % sudo gem install foo

Or you do a local install. 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."

If it isn't a good Ruby solution, it's not a good solution. Pandering to
a single platform is most certainly not a good solution. Pandering to
two platforms is equally a bad solution. Pandering to +n+ solutions is
even worse. Writing a good solution -- and this *is* RubyGems -- that
offers hooks for packagers to use *while using the existing
infrastructure* is a much better option for Ruby and for everyone else.

-austin
--
Austin Ziegler * halostatue / gmail.com
               * Alternate: austin / halostatue.ca