Gem-only releases

Ruby
1

Hi there. This request goes mostly to library authors that
just love gems, which seem to be an increasingly number
of them lately especially in conjunction with rake and
Rakefiles. :slight_smile:

I have noticed that quite a lot of library writers do make gem
only releases. Now first, let me say, I do not have a huge
problem with gem itself. I can see especially Windows users
benefitting from that. For me though it is a lesser problem
which gem seems to solve for several reasons, but before
I decide to go off-topic and explain lengthy, making this mail
longer, let me just state that I agree that “rubygem”
itself is important and good to have.

My point now is, though - please please please - consider
to also release non-gem versions IF you do release a
gem version of your library!

I am aware that a user can probably easily repackage a .gem
file on his/her own, or you could just tell a user that
you will only maintain the .gem and he should use it
too, for me though I would want to have the option to
NOT use gems if there are other options available.
It feels like a tiny bit of freedom in choice - and
yes, it is not a big issue anyway. But enough to
mention it. :wink:

The other, more profound reason is that I myself was
sometimes not able to repackage a .gem.
Blame my incompetence for this.

I’d personally simply prefer if I’d have a .tar.gz or .tar.bz2
(I repackage locally to .tar.bz2 anyway via a ruby script)

Sometimes an author seems to be unsure what to release too,
one example mkrf (i hope the author forgives me for using
his decent project as example):

http://rubyforge.org/frs/?group_id=1748&release_id=11072

You can see the releases sometimes being .gem only, or
.gem + zip … or .gem + .tgz :wink:

Better examples (for me, as a user) would be
http://rubyforge.org/frs/?group_id=12&release_id=11315
as the latest releases seem to be in .gem .tar.gz and .tar.bz2

I get to choose whether to use .gem or not.

Maybe I could persuade the one or other to consider. :slight_smile:

2

On 5/4/07, Marc H. [email protected] wrote:

My point now is, though - please please please - consider
to also release non-gem versions IF you do release a
gem version of your library!

I read through your post a couple of times and I still haven’t found
the part where you explain why gems aren’t getting the job done, and
why library authors should therefore provide their libraries in
non-gem formats.

3

On 05/04/2007 08:56 AM, Lyle J. wrote:

On 5/4/07, Marc H. [email protected] wrote:

My point now is, though - please please please - consider to
also release non-gem versions IF you do release a gem version
of your library!

I read through your post a couple of times and I still haven’t
found the part where you explain why gems aren’t getting the
job done, and why library authors should therefore provide
their libraries in non-gem formats.

This may not be the OP’s reason, but it does point out reasons
why some people/projects do not want to use gems:
http://pkg-ruby-extras.alioth.debian.org/rubygems.html

4

Marc H. [email protected] writes:

My point now is, though - please please please - consider
to also release non-gem versions IF you do release a
gem version of your library!

+1, full ACK.

5

I really do not understand this stance against Rubygems. It seems to me
that
the only problem they have with Gems is that there’s no control over
where
gems are installed. Do they have the same problem with Pear (PHP), CPAN
(Perl), and Packman (Python)?

Personally, while I like apt, I absolutely despise dealing with the
debian
package repositories as packages are split up and spread out in the most
inane ways (you need ruby1.8, libruby1.8, libruby1.8-extras, and the
related
-devel packages most of the time, vs emerge ruby / windows one-click
installer).

So I’m not going to worry too much about that post, and yeah, I’m
curious as
to what the OP finds wrong with using gems.

Jason

6

On 5/7/07, Jason R. [email protected] wrote:

I really do not understand this stance against Rubygems. It seems to me that
the only problem they have with Gems is that there’s no control over where
gems are installed. Do they have the same problem with Pear (PHP), CPAN
(Perl), and Packman (Python)?

I suspect that the key concept which the debian maintainers have is
summed up in this statement from
http://pkg-ruby-extras.alioth.debian.org/rubygems.html

* Rubygems is source-intrusive. The require instruction is replaced

by a
require_gem instruction to allow for versioned dependencies.
Debian and most other systems think that dealing with versioned
dependencies outside of the source is a better idea.

I believe that some of their other arguments against gems are either
untrue, debatable or spring from the above. Note that require_gem is
obsolete, but that’s not really the point.

I’m not sure I see how gems violates the FHS. I think that the
problems are more with Debians use of the FHS.

The thing which gem does which seems unusual from the viewpoint of
packaging schemes such as debian and RPM is that it allows multiple
versions to be installed in parallel on the target machine. As I
understand it, Debian strives to have a single consistent set of
packages installed at any given time with the packaging system
ensuring the consistency. Another way of looking at this is that the
latest possible time to do version binding is at package
install/upgrade time.

On the other hand, this is problematical in a dynamically bound
environment such as is provided by Ruby. The ability to have multiple
versions of gems installed and dynamically resolve versions at
run-time is powerful and fits right in with the other dynamic features
of Ruby.

I think that the debian opposition to gems is just another example of
programmers with exposure only to static languages missing the
differences between dynamic languages and what they are used to.

Just a personal observation.

Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

7

On 5/7/07, Jason R. [email protected] wrote:

I really do not understand this stance against Rubygems.

Me neither.

Personally, while I like apt, I absolutely despise dealing with the debian
package repositories as packages are split up and spread out in the most
inane ways (you need ruby1.8, libruby1.8, libruby1.8-extras, and the related
-devel packages most of the time, vs emerge ruby / windows one-click
installer).

#!/bin/sh

yes |
for x in apt-cache search ruby \ | grep 1.8 \ | sort \ | awk 'BEGIN { FS = " - " } { print $1 }'; do
apt-get install $x;
done

8

quoth the Lyle J.:

On 5/4/07, Marc H. [email protected] wrote:

My point now is, though - please please please - consider
to also release non-gem versions IF you do release a
gem version of your library!

I read through your post a couple of times and I still haven’t found
the part where you explain why gems aren’t getting the job done, and
why library authors should therefore provide their libraries in
non-gem formats.

Well, personally, I like choice so I provide my libs in gems, and also
in
tarballs/zips for the non-gems using Unix/Windows crowd.

The problem now arises in apps that use said libs. If the lib was
installed
via gems then the app needs “require ‘rubygems’” to work. This will
throw an
error for those folks who prefer not to use gems, and don’t have it
installed. So: I have to put boilerplate in the app:

begin
require ‘rubygems’
rescue LoadError
end

so that it may work for both. I plain and simple don’t understand why
the “require ‘rubygems’” is required (pardon the pun), to make gem
installed
libs visable to Ruby.

Now really, I’m just a dilatant in this whole software development biz
and
realize the core Ruby hackers are a lot smarter than me, so I am sure
there
is a sound technical reason for it or it wouldn’t be. That said, I would
sure
love to hear a rational for it…

-d

9

On May 8, 2007, at 4:14 AM, Jason R. wrote:

I read through your post a couple of times and I still haven’t
found the part where you explain why gems aren’t getting the
job done, and why library authors should therefore provide
their libraries in non-gem formats.

This may not be the OP’s reason, but it does point out reasons
why some people/projects do not want to use gems:
http://pkg-ruby-extras.alioth.debian.org/rubygems.html

–
Glen
Gems isn’t perfect. It’s pretty good, but not perfect. It could offer
more information about packages. Also, the gem list is getting longer
by the day. Of course it is pretty easy to narrow a gem listing by
give a letter or 2 or 3 as arguments but that isn’t very helpful.
Some categories would be useful. Heck, a GUI of some sort might be
needed soon. Actually, a widget/gadget tool would be excellent.

10

On Tue, May 08, 2007 at 06:27:56AM +0900, darren kirby wrote:

begin
require ‘rubygems’
rescue LoadError
end

export RUBYOPT=rubygems

(this works for most cases; where it doesn’t work is in specifying a
file to require on the command line with -r)

so that it may work for both. I plain and simple don’t understand why
the “require ‘rubygems’” is required (pardon the pun), to make gem installed
libs visable to Ruby.

Now really, I’m just a dilatant in this whole software development biz and
realize the core Ruby hackers are a lot smarter than me, so I am sure there
is a sound technical reason for it or it wouldn’t be. That said, I would sure
love to hear a rational for it…

Rubygems used to use library stubs for transparency. Perhaps one of the
active Rubygems developers can better explain why they were removed.

Paul

11

From: darren kirby [mailto:[email protected]] :

begin

require ‘rubygems’

rescue LoadError

end

so that it may work for both. I plain and simple don’t understand why

the “require ‘rubygems’” is required (pardon the pun), to

make gem installed libs visable to Ruby.

short answer: love. either you love gem or you don’t.

there was another brilliant and apt-like ruby packaging system (rpa)
started by mauricio et al years back, but it was abandon for lack of
support from the masses; (i think) mainly because a lot of those
packages then did not pass rpa standards or may rubyhackers then hated
standards --just my opinionated opinion :slight_smile:

seriously though, these package-related issues have been discussed for
years, pls see the archives.