Why can't Ruby load .gem files directly?

ruby-talk
41

Eivind Eklund wrote:

`gem uninstall thegems`

What if other stuff rely on those gems? Like user-written code?

OK, point. What does apt-get (or ports) do natively to fix this?

Nothing. Nothing at all, which makes it something of a nonsense
question. If something isn't installed by the package management system,
then the package management system can't be responsible for it.

I'm in the middle of discussions so that we can possibly solve this in a
way that at *least* makes the most complex case feasible without adding
all sorts of nonsense requirements to the developer or RubyGems. I
maintain that RubyGems is the *right* solution for Ruby because it both
helps with package management and with API versioning. 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. RubyGems does a stand-up job of managing its
files -- and with a singular exception (binary stubs), those files can
*never* be missed when the package is uninstalled.

[...]

really ideally, they'd be able to hook together nicely -
unfortunately, I'm uncertain if that is doable in practice (for
combined technical and social reasons.)

That's too bad. Imagine if there existed a single piece of code that
allowed apt-get to interact with .gem files and gems.rubyforge.com.
That would allow apt-get users to control Ruby libs, and wouldn't
require each lib to be repackaged for apt-get specifically.

(It would't obviate all those differences you've pointed out, of
course.)

Heck, since Debian is a binary distribution, there's nothing that stops
Debian repackagers from creating .debs that contain customised .gem
files that are compiled for particular platforms. It's that simple.

-austin

···

On 10/2/05, Devin Mullins <twifkak@comcast.net> wrote:

On 10/2/05, Devin Mullins <twifkak@comcast.net> wrote:

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

42

Why?

What compelling reason is there to use "gem install" over "tar xf"?

There are many cases where "gem install" is not suitable, but "tar xf" is.

Josh

···

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.

43

> Eivind Eklund wrote:
>>>`gem uninstall thegems`
>> What if other stuff rely on those gems? Like user-written code?
> OK, point. What does apt-get (or ports) do natively to fix this?

Nothing. Nothing at all, which makes it something of a nonsense
question.

Actually, at least ports does something about this, though it's
somewhat subtle: It leaves the dependencies behind, and
listable/deletable by the user using the standard tools.

This avoids breaking user code, at the expense of fairly often leaving
unwanted packages behind.

I'm in the middle of discussions so that we can possibly solve this in a
way that at *least* makes the most complex case feasible without adding
all sorts of nonsense requirements to the developer or RubyGems. I
maintain that RubyGems is the *right* solution for Ruby because it both
helps with package management and with API versioning. 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.

I also think that an integration is the way to go. I am uninterested
in which package manager does the actual file copy; I just think the
metadata (at least that the package is installed) needs to be
available from both for things to work right.

The FreeBSD CPAN integration is such that when I install a package
using CPAN, it show up in the local *FreeBSD* package database, and
believe I install a Perl package using ports it also show up in the
local CPAN metadata (though I'll admit I never look at that, so I
don't know.) This also mostly follow my local operating system
policies.

I hope we can find some way of achieving the same or better
integration with RubyGems - I think the way to get there is to just
solve one problem at a time, until things work right.

Eivind.

···

On 10/3/05, Austin Ziegler <halostatue@gmail.com> wrote:

On 10/2/05, Devin Mullins <twifkak@comcast.net> wrote:
>> On 10/2/05, Devin Mullins <twifkak@comcast.net> wrote:

44

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.

What compelling reason is there to use "gem install" over "tar xf"?

Every reason.

There are many cases where "gem install" is not suitable, but "tar
xf" is.

I'd love to know one, for a .gem. Seriously. There's absolutely *no*
advantage to untarring a gem, and (IMO) serious disadvantages. Why would
you even think about forgoing what RubyGems offers?

And, frankly, if you're on Windows, "tar xf" is never the right answer.

This is why a Ruby solution is superior -- it's platform agnostic. It's
also why *I* will never accept a solution that *solely* goes a Unix way.

-austin

···

On 10/2/05, Joshua Haberman <joshua@reverberate.org> wrote:

On Oct 2, 2005, at 4:00 PM, Austin Ziegler wrote:

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

45

I believe that RubyGems currently asks whether a dependency should be
removed or not. This can be something that could be turned into a
policy on a system.

-austin

···

On 10/3/05, Eivind Eklund <eeklund@gmail.com> wrote:

On 10/3/05, Austin Ziegler <halostatue@gmail.com> wrote:
> On 10/2/05, Devin Mullins <twifkak@comcast.net> wrote:
> > Eivind Eklund wrote:
> >> On 10/2/05, Devin Mullins <twifkak@comcast.net> wrote:
> >>>`gem uninstall thegems`
> >> What if other stuff rely on those gems? Like user-written code?
> > OK, point. What does apt-get (or ports) do natively to fix this?
>
> Nothing. Nothing at all, which makes it something of a nonsense
> question.

Actually, at least ports does something about this, though it's
somewhat subtle: It leaves the dependencies behind, and
listable/deletable by the user using the standard tools.

This avoids breaking user code, at the expense of fairly often leaving
unwanted packages behind.

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

46

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.

The package install/uninstall are only easy if your system setup matches the assumptions implicit in the design of the "gem" command.

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.

- 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

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.

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

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.

Josh

···

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:

47

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

···

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:

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

48

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

···

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:

49

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

···

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:

50

Joshua wrote:
> 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.

Since I'm unable to understand what you mean here, I'd appreciate it
being spelled out. My understanding matches Joshua's at this point,
and I'm wondering whether it's you or us that's missing something.

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

It has to do with the layout policies of the platform it is being
installed on, and how directories are supposed to be picked by
software. That's normally managed by the package manager & packagers.
When RubyGems is taking that role, it suddenly ends up having to do
with RubyGems.

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

You misunderstood the comment here, I think.

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

That's religious. There are, as far as I know, still cases where
RubyGems do not work correctly with the local packaging systems
(unless somebody has been doing magic overnight :slight_smile: For those that see
those local policies as more important than whatever RubyGems offers,
"gem install" is inappropriate. I can list cases easily, and so can
you.

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.

True.

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.

Pandering to a single language - by breaking policies - is a bad
solution for any platform. Pandering to +n+ languages 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.

The question is "Do RubyGems offer hooks that work correctly for repackagers?"

At present, with my repackager hat on, I'll say the answer is a "no".

The important question is "How can we make the answer to that question
a 'Yes', and keep present good aspects?"

Eivind.

···

On 10/3/05, Austin Ziegler <halostatue@gmail.com> wrote:

51

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.

Yes, absolutely. My gem installation directory is read-only except during the
install process.

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

For libraries that should be sufficient. For gems that contain executable
programs, you would need to deal with that. When gems starts supporting a
separate data directory, you need to deal with that as well. If gems ever
starts allowing post-install scripts, then all bets are off.

···

On Monday 03 October 2005 02:20 am, Joshua Haberman wrote:

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

52

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

···

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:

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