# RubyGems woes **URL:** \ **Category:** Ruby\ **Created:** [September 28, 2009, 8:50pm UTC](https://www.ruby-forum.com/t/rubygems-woes/176302 "2009-09-28T20:50:23Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![murfhy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/d26b3c/32.png) [@murfhy](https://www.ruby-forum.com/u/murfhy)\ **Post date:** [September 28, 2009, 8:50pm UTC](https://www.ruby-forum.com/t/rubygems-woes/176302/1 "2009-09-28T20:50:23Z")
We’re trying to support both MRI and JRuby for a project, and have a number of “internal” gems our software is packaged into. What would be _great_ is a means to have variadic gem dependencies, selected based on the current RUBY\_ENGINE. Many of the gems we need on MRI are irrelevant on JRuby or require JRuby-specific alternatives. Since I don’t have this, I’ve ended up making two gem servers, one for MRI and one for JRuby. I’ve ended up loading the JRuby server with some “dummy” gems which don’t actually do anything but fulfill the gem dependencies for gems that aren’t needed on JRuby. This seems like a bit of a hack. Does anyone have a better solution for this? ---
**Author:** ![murfhy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/d26b3c/32.png) [@murfhy](https://www.ruby-forum.com/u/murfhy)\ **Post date:** [September 28, 2009, 9:20pm UTC](https://www.ruby-forum.com/t/rubygems-woes/176302/2 "2009-09-28T21:20:27Z")
I don’t know what the output for these would be, but are you familiar with the following environment variables: RUBY\_DESCRIPTION RUBY\_PLATFORM RUBY\_VERSION ? Maybe they’ll come in handy. ---
**Author:** ![murfhy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/d26b3c/32.png) [@murfhy](https://www.ruby-forum.com/u/murfhy)\ **Post date:** [September 28, 2009, 9:25pm UTC](https://www.ruby-forum.com/t/rubygems-woes/176302/3 "2009-09-28T21:25:24Z")
> I’ve ended up loading the JRuby server with some > “dummy” > gems which don’t actually do anything but fulfill the gem dependencies > for > gems that aren’t needed on JRuby. This seems like a bit of a hack. > > Does anyone have a better solution for this? The last section of [http://wiki.github.com/rogerdpack/ruby\_code\_tutorials/gem](http://wiki.github.com/rogerdpack/ruby_code_tutorials/gem) might be helpful. -r ---
**Author:** ![murfhy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/d26b3c/32.png) [@murfhy](https://www.ruby-forum.com/u/murfhy)\ **Post date:** [September 29, 2009, 4:47am UTC](https://www.ruby-forum.com/t/rubygems-woes/176302/4 "2009-09-29T04:47:30Z")
On Mon, Sep 28, 2009 at 1:25 PM, Roger P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > The last section of > [http://wiki.github.com/rogerdpack/ruby\_code\_tutorials/gem](http://wiki.github.com/rogerdpack/ruby_code_tutorials/gem) > might be helpful. Looking at this: [http://github.com/mark-moseley/ruby-debug-ide/blob/master/ext/mkrf\_conf.rb](http://github.com/mark-moseley/ruby-debug-ide/blob/master/ext/mkrf_conf.rb) I’m a bit confused… does this replace the normal RubyGems dependency mechanism? (i.e. dependencies specified in the GemSpec) ---
**Author:** ![murfhy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/d26b3c/32.png) [@murfhy](https://www.ruby-forum.com/u/murfhy)\ **Post date:** [October 7, 2009, 7:14am UTC](https://www.ruby-forum.com/t/rubygems-woes/176302/5 "2009-10-07T07:14:51Z")
On Tue, Sep 29, 2009 at 4:46 AM, Roger P. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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. - Charlie ---
**Author:** ![murfhy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/d26b3c/32.png) [@murfhy](https://www.ruby-forum.com/u/murfhy)\ **Post date:** [September 29, 2009, 4:46pm UTC](https://www.ruby-forum.com/t/rubygems-woes/176302/6 "2009-09-29T16:46:15Z")
> Looking at this: > > [http://github.com/mark-moseley/ruby-debug-ide/blob/master/ext/mkrf\_conf.rb](http://github.com/mark-moseley/ruby-debug-ide/blob/master/ext/mkrf_conf.rb) > > I’m a bit confused… does this replace the normal RubyGems dependency > mechanism? (i.e. dependencies specified in the GemSpec) Let’s see…no. The itch that needs scratching is gem dependencies that differ per platform and per ruby version. In theory there’s a few ways to get those “platform specific gems” installed. 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 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]. You maybe could leverage the new hooks that gems provides. Or you could “hack” the extconf.rb to install system dependent gems. This is the equivalent of putting the “install\_gem\_gem1\_platform\_dependencies” functionality into extconf.rb itself, thus there aren’t two steps for a user to run to install a gem. HTH. -r ---
**Author:** ![murfhy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/d26b3c/32.png) [@murfhy](https://www.ruby-forum.com/u/murfhy)\ **Post date:** [October 7, 2009, 9:40am UTC](https://www.ruby-forum.com/t/rubygems-woes/176302/7 "2009-10-07T09:40:37Z")
On Oct 7, 7:14 am, Charles Oliver N. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > 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/](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](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. ---
**Author:** ![murfhy](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/d26b3c/32.png) [@murfhy](https://www.ruby-forum.com/u/murfhy)\ **Post date:** [October 7, 2009, 6:19pm UTC](https://www.ruby-forum.com/t/rubygems-woes/176302/8 "2009-10-07T18:19:56Z")
On Mon, Sep 28, 2009 at 2:49 PM, Tony A. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > gems that aren’t needed on JRuby. Â This seems like a bit of a hack. > > Does anyone have a better solution for this? Have you looked at rip? [http://hellorip.com/about.html](http://hellorip.com/about.html) Maybe you could package jruby-deps.rip and mri-deps.rip or something similar…just a thought. Best, Michael G.