Use Non-Java Version of Gem

Hello all,

I’m writing a program that may or may not require to be run in JRuby,
depending on the interface wanted by the user. A couple of the gems I’m
using in the project have different versions based on whether JRuby is
used. One example is the SQLite3 library for DataObjects (do_sqlite3). I
installed the gem using Ruby via ‘gem install do_sqlite3’ and using
JRuby via ‘jruby -S gem install do_sqlite3’. This resulted in two gems
actually being installed:

do_sqlite3-0.10.1.1-java
do_sqlite3-0.10.1.1

The only difference between the two gems is do_sqlite3.so vs
do_sqlite3.jar.

When I run my program via Ruby it still tries to use the
do_sqlite3-0.10.1.1-java gem (I assume because it comes first on the
file system). I had assumed that rubygems would only load the -java
versions of gems when the RUBY_PLATFORM was java, but I guess that’s not
the case. Is it possible for me to force the non-java version of the gem
to be used when the RUBY_PLATFORM is not java?


Thanks!
Bryan

On Jan 27, 9:43 pm, Bryan R. [email protected] wrote:

do_sqlite3-0.10.1.1-java
to be used when the RUBY_PLATFORM is not java?

That means you installed “-java” version of the gem in MRI.

Using normal gem installation process, that gem will not be installed.
Depending on “do_sqlite3” will resolve to the appropriate platform
version.

You should remove java version from your Ruby installation and try
packaging your gem with the do_sqlite3 dependency.

Then a normal gem installation will trigger the dependency and the
proper platform depending on the Ruby interpreter used by the user (or
you)

Luis L. wrote:

That means you installed “-java” version of the gem in MRI.

On my machine, the gem path for both ruby and jruby are the same. So,
whether or not I use the gem command or jruby -S gem to install gems,
they both get installed to the same directory.

Using normal gem installation process, that gem will not be installed.
Depending on “do_sqlite3” will resolve to the appropriate platform
version.

So what happens if a user installs my application’s gem using “jruby -S
gem install”, which will install the “-java” version of do_sqlite3, but
they already have another normal ruby application that depends on
do_sqlite3 as well? Won’t they incur the same problem I’m having here
since gems installed by both ruby and jruby are stored in the same
directory?

You should remove java version from your Ruby installation and try
packaging your gem with the do_sqlite3 dependency.

I don’t currently have my application packaged up as a gem yet, but I
get your point here.

Then a normal gem installation will trigger the dependency and the
proper platform depending on the Ruby interpreter used by the user (or
you)

Right, which could still lead to the problem I’m currently having, as
described above.

Thoughts? Thanks for the help!!!

Hassan S. wrote:

Ouch – how did you wind up with that? In any case, that’s the root
of your problem: they should be entirely separate.

Ah… okay, good to know this is not the correct way for things to be.
:slight_smile: I have a custom GEM_HOME and GEM_PATH specified in my .bashrc file
such that I don’t have to be root to install gems and multiple users on
my machine can have their own gem space.

I wonder if this is why both Ruby and JRuby are using the same space? Is
there a way to specify a different GEM_PATH for JRuby?

On Thu, Jan 28, 2010 at 7:17 AM, Bryan R.
[email protected] wrote:

On my machine, the gem path for both ruby and jruby are the same. So,
whether or not I use the gem command or jruby -S gem to install gems,
they both get installed to the same directory.

Ouch – how did you wind up with that? In any case, that’s the root
of your problem: they should be entirely separate.

Bryan R. wrote:

Hassan S. wrote:

Ouch – how did you wind up with that? In any case, that’s the root
of your problem: they should be entirely separate.

Ah… okay, good to know this is not the correct way for things to be.
:slight_smile: I have a custom GEM_HOME and GEM_PATH specified in my .bashrc file
such that I don’t have to be root to install gems and multiple users on
my machine can have their own gem space.

That’s unnecessary. gem will automatically install in ~/.gems if it
can’t install system gems.

I wonder if this is why both Ruby and JRuby are using the same space? Is
there a way to specify a different GEM_PATH for JRuby?

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

On Thu, Jan 28, 2010 at 8:07 AM, Bryan R.
[email protected] wrote:

Ah… okay, good to know this is not the correct way for things to be.
:slight_smile: I have a custom GEM_HOME and GEM_PATH specified in my .bashrc file
such that I don’t have to be root to install gems and multiple users on
my machine can have their own gem space.

I wonder if this is why both Ruby and JRuby are using the same space? Is
there a way to specify a different GEM_PATH for JRuby?

Sorry, I’ve never had a reason to manually tinker with GEM_HOME or
GEM_PATH so can’t answer that.

Good luck!

Marnen Laibow-Koser wrote:

That’s unnecessary. gem will automatically install in ~/.gems if it
can’t install system gems.

Okay, so I removed the GEM_HOME and GEM_PATH specifications in my
.bashrc, made sure the environment variables were no longer set, and ran
‘gem environment’ and ‘jruby -S gem environment’. Both still show the
same gem paths… :frowning:

Is there a reason why jruby doesn’t use
‘/usr/local/lib/jruby-1.3.1/lib/ruby/gems/1.8/’ for storing gems
installed using jruby? I never told it not to, but I never told it to
either, so I’m not sure what the normal process is.

On Thu, Jan 28, 2010 at 9:25 AM, Bryan R.
[email protected] wrote:

Is there a reason why jruby doesn’t use
‘/usr/local/lib/jruby-1.3.1/lib/ruby/gems/1.8/’ for storing gems
installed using jruby? I never told it not to, but I never told it to
either, so I’m not sure what the normal process is.

The “normal process” is indeed to save gems to that location. I’m
not sure how/where the old GEM_PATH stuff is being cached but
that appears to be the case.

If I were you, I’d either delete and reinstall 1.3.1. or upgrade to
1.4.0
and start over. Hopefully your gem environment will be “clean” from
that point.

On Thu, Jan 28, 2010 at 11:06 AM, Bryan R.
[email protected] wrote:

  • GEM PATHS:
    • /home/btricha/.gems
    • /var/lib/gems/1.8

By contrast, here’s the comparable output from my system:

ripple:~$ which jruby
/usr/local/jruby-1.4.0/bin/jruby
ripple:~$ jruby -S gem env
RubyGems Environment:

  • RUBYGEMS VERSION: 1.3.5
  • RUBY VERSION: 1.8.7 (2009-11-02 patchlevel 174) [java]
  • INSTALLATION DIRECTORY: /usr/local/jruby-1.4.0/lib/ruby/gems/1.8
  • RUBY EXECUTABLE: /usr/local/jruby-1.4.0/bin/jruby
  • EXECUTABLE DIRECTORY: /usr/local/jruby-1.4.0/bin
  • RUBYGEMS PLATFORMS:
    • ruby
    • universal-java-1.6
  • GEM PATHS:
    • /usr/local/jruby-1.4.0/lib/ruby/gems/1.8
    • /Users/hassan/.gem/jruby/1.8

So it seems that somewhere in your environment there’s still some
reference to your previous configuration. Just out of curiousity, what
does gem env using MRI return?

Hassan S. wrote:

So it seems that somewhere in your environment there’s still some
reference to your previous configuration. Just out of curiousity, what
does gem env using MRI return?

[email protected]:~$ gem env
RubyGems Environment:

  • RUBYGEMS VERSION: 1.3.5
  • RUBY VERSION: 1.8.7 (2009-06-12 patchlevel 174) [i486-linux]
  • INSTALLATION DIRECTORY: /home/btricha/.gems
  • RUBY EXECUTABLE: /usr/bin/ruby1.8
  • EXECUTABLE DIRECTORY: /home/btricha/.gems/bin
  • RUBYGEMS PLATFORMS:
    • ruby
    • x86-linux
  • GEM PATHS:
    • /home/btricha/.gems
    • /var/lib/gems/1.8
  • GEM CONFIGURATION:
    • :update_sources => true
    • :verbose => true
    • :benchmark => false
    • :backtrace => false
    • :bulk_threshold => 1000
    • “gempath” => ["/home/btricha/.gems", “/var/lib/gems/1.8”]
    • :sources => [“http://gemcutter.org”,
      http://gems.rubyforge.org/”]
    • “gemhome” => “/home/btricha/.gems”
  • REMOTE SOURCES:

Hassan S. wrote:

If I were you, I’d either delete and reinstall 1.3.1. or upgrade to
1.4.0
and start over. Hopefully your gem environment will be “clean” from
that point.

Okay, so I upgraded to JRuby 1.4.0 by downloading the source tar file
from the JRuby website and building with ant. Now, when I run the
following command from the jruby-1.4.0 directory, I get the following
result:

[email protected]:/usr/local/lib/jruby-1.4.0$ bin/jruby -S gem environment
RubyGems Environment:

  • RUBYGEMS VERSION: 1.3.5
  • RUBY VERSION: 1.8.7 (2010-01-28 patchlevel 174) [java]
  • INSTALLATION DIRECTORY: /home/btricha/.gems
  • RUBY EXECUTABLE: /usr/local/lib/jruby-1.4.0/bin/jruby
  • EXECUTABLE DIRECTORY: /home/btricha/.gems/bin
  • RUBYGEMS PLATFORMS:
    • ruby
    • universal-java-1.6
  • GEM PATHS:
    • /home/btricha/.gems
    • /var/lib/gems/1.8
  • GEM CONFIGURATION:
    • :update_sources => true
    • :verbose => true
    • :benchmark => false
    • :backtrace => false
    • :bulk_threshold => 1000
    • “install” => “–env-shebang”
    • “update” => “–env-shebang”
    • “gempath” => ["/home/btricha/.gems", “/var/lib/gems/1.8”]
    • “gemhome” => “/home/btricha/.gems”
    • :sources => [“http://gems.rubyforge.org/”,
      http://gemcutter.org”]
  • REMOTE SOURCES:

Thoughts? :frowning:

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs