a) have some compiled-in option to specify a default
b) do what irb and gem bin scripts do -
check if a) exists and then just add those 3 extra lines to the top
of each bin script (improve the bin scripts template).
Well you are right in the sense that we can make a symlink into
the ruby installation.
# Like this:
ln -sf /opt/rvm/gems/ree-1.8.7-2010.01 /opt/rvm/rubies/ree-1.8.7-2010.01/lib/ruby/gems/1.8
Actually I'm pretty miffed why this issue is marked as
"Resolved" so quickly. Because its rather 'assuming too much' to
expect all future rubies to adhere to this MRI site directory
structure. Its brittle and will break easily. As shown with rvm. So
I am suggesting we could re-think the following method:
if defined? RUBY_FRAMEWORK_VERSION then
File.join File.dirname(ConfigMap[:sitedir]), 'Gems',
# 1.9.2dev reverted to 1.8 style path
elsif RUBY_VERSION > '1.9' and RUBY_VERSION < '1.9.2' then
File.join(ConfigMap[:libdir], ConfigMap[:ruby_install_name], 'gems',
File.join(ConfigMap[:libdir], ruby_engine, 'gems',
And provide some clearly exposed API / way to set the default
path here. Even if its just something statically defined in a file.
I can we get it from ConfigMap[:sitedir]. Well we
maybe could introduce a new variable
Support Staff5 Posted by Eric Hodel on 25 Jan, 2010 10:28 PM
RubyGems pulls the information needed to work from rbconfig.rb
for the ruby that is executing whichever gem-installed executable
you're using. There is no need to set GEM_HOME or GEM_PATH to any
defaults as those are determined directly from rbconfig.rb.
If rvm is breaks when using RubyGems then rvm has a bug, not
If rvm isn't installing gems in the correct place then it needs
to set GEM_HOME and GEM_PATH for you, or provide a defaults
override as described under the heading "RubyGems Defaults,
Packaging" for ri Gem.