On May 13, 2011, at 07:55 , Stephen Bannasch wrote: > How are people using GEM_HOME, in what situations and when (if ever) should > it be ignored.
I don't know how to answer your "how" question, but your when question is: It shouldn't ever be ignored. > I recently fixed a bug in JRuby that so far would only be exposed to a user > when they install jruby-head using RVM. > > rvm install jruby-head rewrite's the current rakes hash-bang > invocation to be: #!/usr/bin/env jruby > > http://jira.codehaus.org/browse/JRUBY-5791 > > The problem occurred because during the install rvm had already defined > GEM_HOME and it referenced a specific MRI Ruby that was not JRuby. Part of > the ant distribution install scripts for JRuby install specific gems. When > JRuby was running this task Gem.ruby referenced the JRuby executable but > Gem.bindir referenced the original GEM_HOME defined when the install > invocation was made. > > Before fixing this issue one of the results was that jruby installed it's > gems into the MRI GEM_HOME. Correct. All installs go into GEM_HOME. > I modified the specific ant task to unset GEM_HOME during the install so the > JRuby uses a gem home based on the executing JRuby instance. That's probably the best way to do it if I'm understanding your problem correctly. I think this is only correct because you're inside the context of an ant task, and that's unambiguously jruby-space. > I realized also that if I have GEM_HOME defined and referencing a different > Ruby VM and I just run JRuby directly it will also be running with Gem.ruby > and Gem.bindir referencing resources in separate Ruby VMs. > > I've entered an issue in the JRuby issue tracker here: > > http://jira.codehaus.org/browse/JRUBY-5795 > JRuby uses incorrect Gem.bindir when env var GEM_HOME points elsewhere > > It's not clear to me what should happen when one Ruby VM is running (with > GEM_HOME defined) and another Ruby VM starts up in the same environment. I > suspect this occurs infrequently but might happen more often with JRuby. > > Which leads me back to my initial question: how is GEM_HOME being used now? GEM_HOME is essentially the writable portion of GEM_PATH. I think ticket 5795 is correct in that it CAN lead to confusing errors... but I think it is the way we should do it. I get bit once in a while because I do this in my shell setup: export GEM_PATH=`gem env home` and if I turn around and use ruby 1.9 it will cause problems with binary gems. Most of this is taken care of for me by using isolate in every project I work on, but that's a special case, not the norm. _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems Rubygems-developers@rubyforge.org http://rubyforge.org/mailman/listinfo/rubygems-developers
