From: Luis Lavena <luislavena@...>
Date: 2009-10-07T16:40:07+09:00
Subject: Re: RubyGems woes

On Oct 7, 7:14 am, Charles Oliver Nutter <head...@headius.com> wrote:
> On Tue, Sep 29, 2009 at 4:46 AM, Roger Pack <rogerpack2...@gmail.com> wrote:
> > You could create an executable called
> > install_gem_xxx_platform_dependencies
>
> > then users have to do
>
> > $ gem install gem1
> > $ install_gem_gem1_platform_dependencies # installs more gems for you
>
> Sorry, but this strikes me as pretty gross :(
>
> > You might be able to create different version of the same gem, that
> > target different platforms, like
> > gem1-mswin32-60 and gem1-jruby-60
> > and have different dependencies listed in each.  correct me if I'm wrong
> > but I think this still would not allow for gem1-mswin32-60 to install
> > different gems based on the ruby version [i.e. different for 1.8 and
> > 1.9].
>
> This and the other workarounds also seem pretty gross...I feel like
> RubyGems should be doing this for you. And the problem is just going
> to get worse as we have more Ruby impls coming online.
>

This brings again the issue that RubyGems has not been prepared to
deal with multiple implementations.

http://blog.phusion.nl/2009/02/02/getting-ready-for-ruby-191/

Or multiple versions either:

http://rubyforge.org/pipermail/rubygems-developers/2009-April/004522.html

You can't even tell RubyGems that "support 1.8 greater than 1.8.5 and
1.9 too"

Fix those issues seems important, and even more when developers try to
create tools or libraries that works seamlessly across versions AND
implementations of Ruby.

A recommended approach is wrap requirements into rescue blocks and
nice warnings, provide install message when the gem get installed and
also as the gem requirements text.

--
Luis Lavena