On 10/3/05, Joshua Haberman <joshua / reverberate.org> wrote:
> 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.

Um. I'm really *not* getting what you're wanting here. If you're wanting
the runtime to solve the problem, then you're *needing* the stuff
installed in the same way that the runtime expects it for version
handling. This is *best* handled with "gem install", not with "tar xf".

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

The "assumptions" have to do with the runtime -- not the installer. The
installer merely assumes that it has write access during installation to
something parallel to the Ruby core and site_ruby directories. In my
case, on Windows, that's "../lib/ruby/gems/...". By the way, I *often*
copy my installations from one Windows PC to another. My main laptop's
power connection died last week, so I installed Ruby 1.8.2 on an
alternate laptop and copied my entire Ruby directory to the laptop in
question. The only concern was the stuff in bin/, because that's got
.cmd files that have explicit paths in them. Everything else is just
Handled Properly.

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

Yes on all four counts.

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

As Jim has said, yes, it will. The only *potential* problem you'll have
are gems that assume that the area is writeable. I think that Instiki
was the only gem that did this, and that may have been fixed up as well.
None of my gems assume that. They *do*, however, assume that the data is
relative to the local installation because there's no general DATADIR
solution for Ruby.

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

As I pointed out above, I more or less do that on Windows all the time.
I see no reason that it wouldn't work on any other platform -- and with
the way that Gems are constructed, I see no reason that it wouldn't work
even cross-platform for non-compiled gems.

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

Yes, I was misunderstanding the use case. I still don't think that it's
an issue. As I said, when I had to do a quick recovery from my dead
laptop, I just copied my gems directory to the new installation of Ruby
-- and it all just worked.

This is *part* of the reason that I am consistently annoyed at what I
see as obstructionism to RubyGems. A lot of questions are raised by
people who don't know anything about RubyGems -- and all of them could
be answered by (1) reading the code or (2) experimenting. RubyGems is
more flexible than people think it is, because even for compiled gems,
it inherits Ruby's way of handling multiple architectures.

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