Home → Problems →

Default $GEM_PATH and $GEM_HOME

Admin Functions

• Remove

dreamcat4

25 Jan, 2010 05:29 PM

hi - can rubygems hardcode the right $GEM_PATH into the bin scripts?
irb and gem seem to do this aleady (note: i mean on ree-1.8.7)

When i run the gem bin script, and haven't got either the $GEM_HOME, or GEM_PATH in my environment.

which github
/opt/rvm/gems/ree-1.8.7-2010.01/bin/github

the github bin script is generated by rubygems during the gem install... command.
in the bin script it will requre rubygems, then require the gem github.
what i'd like to see is what irb does:

less $(which irb)
#!/opt/rvm/rubies/ree-1.8.7-2010.01/bin/ruby
ENV['GEM_HOME']=ENV['GEM_HOME'] || '/opt/rvm/gems/ree-1.8.7-2010.01'
ENV['GEM_PATH']=ENV['GEM_PATH'] || '/opt/rvm/gems/ree-1.8.7-2010.01'
ENV['PATH']='/opt/rvm/rubies/ree-1.8.7-2010.01/bin:/opt/rvm/gems/ree-1.8.7-2010.01/bin:' + ENV['PATH']
...

so you see they are hardcoded in case there is no environment variable.
and to avoid "cannot find gem" error.

looks like rubygems can check the /etc/gemrc... but that didn't work for me!

1. 2 Posted by dreamcat4 on 25 Jan, 2010 05:57 PM

   

   Yeah...

   Should:

   a) have some compiled-in option to specify a default GEM_PATH
   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).

   Admin Functions

   • Split
   • Remove

2. Support Staff 3 Posted by Eric Hodel on 25 Jan, 2010 07:06 PM

   

   It looks like you're running rvm. If you don't use rvm everything works just fine. There's no need to set GEM_HOME or GEM_PATH by default.

   Admin Functions

   • Remove

3. Eric Hodel closed this discussion on 25 Jan, 2010 07:06 PM.

4. dreamcat4 re-opened this discussion on 25 Jan, 2010 10:12 PM

5. 4 Posted by dreamcat4 on 25 Jan, 2010 10:12 PM

   

   Hi,

   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:

   def self.default_dir
     if defined? RUBY_FRAMEWORK_VERSION then
       File.join File.dirname(ConfigMap[:sitedir]), 'Gems',
                 ConfigMap[:ruby_version]
     # 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',
                 ConfigMap[:ruby_version])
     else
       File.join(ConfigMap[:libdir], ruby_engine, 'gems',
                 ConfigMap[:ruby_version])
     end
   end
   

   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 ConfigMap[:gemsdir] then:

   ConfigMap[:gemsdir] ||= ConfigMap[:sitedir]
   

   This is the better solution here.

   Admin Functions

   • Split
   • Remove

6. Support Staff 5 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 RubyGems.

   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.

   Admin Functions

   • Remove

7. Eric Hodel closed this discussion on 25 Jan, 2010 10:28 PM.

Comments are currently closed for this discussion. You can start a new one.