Comment 46 for bug 145267

On Wed, Aug 13, 2008 at 09:20:54AM -0000, Neil Wilson wrote:
> > While testing the package I came across the usage of gem libraries:
> > according to the rubygems documentation, you need to do some
> > post-install work in order to setup ruby gems correctly. I was wondering
> > if the ruby libraries could be symlinked to
> > /usr/local/lib/site_ruby/RUBY_VERSION/ when a gem is installed ? That
> > way you wouldn't have to modify your environment or call ruby with the
> > -rubygems option. Since site_ruby is already versioned
> > update-alternatives is not needed in that case.
>
> The rubygems documentation is somewhat out of date. The way you use
> libraries in a rubygem is simply to do
>
> require 'library'
>
> or if you want a particular version
>
> gem 'gemname', >=2.1.0
> require 'library'
>
> Rubygems monkey-patches the ruby require system so that you get the
> correct gem library automagically. It even works most of the time.
>
> Have you an example that doesn't work like that?

I was using the progressbar example from the rubygems documentation[1]:

The command 'ruby test.rb' fails with a "no such file to load -
progressbar" error message.

The command 'ruby -rubygems test.rb' works as expected.

If I symlink /var/lib/gems/1.8/gems/progressbar-0.0.3/lib/progress.rb in
/usr/local/lib/site_ruby/1.8/, the command 'ruby test.rb' works as
expected.

[1]: http://rubygems.org/read/chapter/4#page16

>
> > I've also come across the following situation:
> >
> > $ sudo gem1.8 install rails
> > $ sudo gem1.9 install rails
> > $ sudo gem1.8 install rails
> >
> > However /usr/local/bin/rake is still using ruby1.9. So gems dependencies
> > are not switched to the ruby version used by the installed gem. Is this
> > a valid use case ? How should it be handled ? Could the slave option of
> > update-alternatives be used to handle binaries from dependencies ?
>
> That's either a bug or a feature depending upon your viewpoint and is
> merely a function of the way gem does reinstalls and handles
> versioning (ie it reinstalls the requested gem, but not its
> dependencies). If you do that with a source installed gem system, you
> would get precisely the same result.
>
> For me its an edge case with no easy win (the list of binaries of all
> the dependencies is not readily available in the program).
>
> Gem's dependency mechanism is primitive and it does get itself in a
> mess if you do anything wildly unorthodox - like uninstall or
> reinstall things :-). For this cycle I'd be happy if gem puts its
> binaries on the system path and doesn't leave junk lying around or
> break things when uninstalling stuff.
>
> Do you consider this a show stopper?
>

So it seems that upstream gem would behave the same way as your
proposal. I don't think it's a show stopper then.

Other comments on the diff between 1.2.0-2 and
1.2.0+2008081301-0ubuntu1~bbox1:

* debian/control:

 You've modified the build-dependencies - you're depending on rdoc
 rather than an explicit version of it. I think keeping the
 dependencies as close as possible to the ones in debian would help.

  ruby-pkg-tools has been dropped - why ?

  rubygems depends on rubygems1.8 *and* ruby. The dependency on ruby
  seems redundant.

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com