Gem-only releases

[Marc Heiler]

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.

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.

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

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.

 

[Lyle Johnson]

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.

 

[Glen Pfeiffer]

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

 

[John Joyce]

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.

 

[Greg Donald]

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

 

[Rick DeNatale]

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.

 

[darren kirby]

quoth the Lyle Johnson:

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

 

[Peña, Botp]

From: darren kirby [mailto:[email protected]] :
# begin
# require 'rubygems'
# rescue LoadError
# end
#=20
# so that it may work for both. I plain and simple don't understand why=20
# the "require 'rubygems'" is required (pardon the pun), to=20
# 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

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

 

[Paul Brannan]

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