why can't Ruby load .gem files directly?

[Austin Ziegler]

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

 

[Corey Lawson]

------=_Part_1166_17001202.1128300374972
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

If it is a debian user problem that is sad, but I have to say that I
try to avoid any libraries that are not packed as a deb. I do not have
gems installed because the duality of the gem and the debian system is
annoying me.

This may be just an anecdote, but a lot of libraries are loosing at
least me as a user. I have packaged deb's myself and I don't think it
is a very complicated process, so I wonder why it is difficult to go
from .gem to .deb?

brian

Well, is there an apt-get for every other OS/Debian besides Debian? Might a=
s
well be a Windows Ruby user being steamed for everything not being packaged
as a .MSI file using the newest Windows Installer, because, well, everythin=
g
else comes packaged that way for Windows, so might as well be consistent,
no?

Again, it's possible to package Ruby libraries not as .gem, just like it is
feasible to package a J2EE web app as something besides a .[jwe]ar, but in
the context of the environments, it's just easier to deal with creating the
[jwe]ar files, and it's just easy enough to use gem to manage gem files.

------=_Part_1166_17001202.1128300374972--

 

[Joshua Haberman]

--Apple-Mail-6--330612629
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
delsp=yes;
format=flowed

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.

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

--Apple-Mail-6--330612629--

 

[Austin Ziegler]

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.

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

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

 

[Joshua Haberman]

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.

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.

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

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

 

[Eivind Eklund]

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.

 

[Eivind Eklund]

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.

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.

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.

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 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. Pan= dering 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 repackager=
s?"

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.

 

[Jim Weirich]

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

Yes, absolutely. My gem installation directory is read-only except durin=
g the=20
install process.

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

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

--=20
-- Jim Weirich (e-mail address removed) http://onestepback.org

 

[Austin Ziegler]

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

 

[Hugh Sasse]

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

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

 

[Austin Ziegler]

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

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.

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