Backport #1773: Gem path doesn't honor user gem?

• Status: Closed
• Assignee: drbrain (Eric Hodel)

[godfat (Lin Jen-Shin)]

=begin
Sorry that I don't have much time to investigate it or
find out if this is fixed in trunk, please tell me if this
is duplicated or fixed, or I need to provide more
information about it.

The problem is that I use only user's gem path
instead of system's gem path. There's no gem
in system's gem path (i.e. /usr/lib/ruby19/gems/1.9.1)

I know that setting $GEM_HOME could resolve this,
but this would be hard to setup correctly between versions of Ruby.
using ENV['GEM_HOME'] = "..."' and Gem.clear_paths' could
resolve too, but it's not that clear, and Gem.set_home, Gem.set_paths,
Gem.use_paths doesn't work well.

p.s. Anything above and below are fine with:
ruby 1.8.7 (2008-12-21 MBARI 6 on patchlevel 72) [i686-linux]
So I suppose this is a bug.

$ gem which rack
(checking gem rack-1.0.0 for rack)
/home/photos/.gem/ruby/1.9.1/gems/rack-1.0.0/lib/rack.rb

$ ruby -ve 'gem "rack"'
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
internal:gem_prelude:234:in push_gem_version_on_load_path': Could not find RubyGem rack (>= 0) (Gem::LoadError) from <internal:gem_prelude>:14:in gem'
from -e:1:in `'

$ cat .gemrc
#gemhome: /home/photos/.gem/ruby/1.8
#gempath: - /home/photos/.gem/ruby/1.8

- /home/photos/.gem/ruby/1.9.1

gem: --no-rdoc --no-ri --user-install --format-executable

$ gem env
RubyGems Environment:

• RUBYGEMS VERSION: 1.3.4
• RUBY VERSION: 1.9.1 (2009-05-12 patchlevel 129) [i686-linux]
• INSTALLATION DIRECTORY: /usr/lib/ruby19/gems/1.9.1
• RUBYGEMS PREFIX: /usr/lib/ruby19/gems/1.9.1/gems/rubygems-update-1.3.4
• RUBY EXECUTABLE: /usr/bin/ruby19
• EXECUTABLE DIRECTORY: /usr/bin
• RUBYGEMS PLATFORMS:
  • ruby
  • x86-linux
• GEM PATHS:
  • /usr/lib/ruby19/gems/1.9.1
  • /home/photos/.gem/ruby/1.9.1
• GEM CONFIGURATION:
  • :update_sources => true
  • :verbose => true
  • :benchmark => false
  • :backtrace => false
  • :bulk_threshold => 1000
  • "gem" => "--no-rdoc --no-ri --user-install --format-executable"
• REMOTE SOURCES:
  • http://gems.rubyforge.org/

$ ruby -ve 'p Gem.path'
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
["/usr/lib/ruby19/gems/1.9.1"]

Gem.set_paths:
$ ruby -ve 'Gem.set_paths("/home/photos/.gem/ruby/1.9.1"); p Gem.path; gem "rack"'
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
["/home/photos/.gem/ruby/1.9.1", "/usr/lib/ruby19/gems/1.9.1"]
internal:gem_prelude:234:in push_gem_version_on_load_path': Could not find RubyGem rack (>= 0) (Gem::LoadError) from <internal:gem_prelude>:14:in gem'
from -e:1:in `'

Gem.set_home:
$ ruby -ve 'Gem.set_home("/home/photos/.gem/ruby/1.9.1"); p Gem.path; gem "rack"'
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
["/usr/lib/ruby19/gems/1.9.1"]
internal:gem_prelude:234:in push_gem_version_on_load_path': Could not find RubyGem rack (>= 0) (Gem::LoadError) from <internal:gem_prelude>:14:in gem'
from -e:1:in `'

Gem.use_paths and calling gem first is fine, but not for require first:
$ ruby -ve 'Gem.use_paths("/home/photos/.gem/ruby/1.9.1"); p Gem.path; gem "rack"'
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
["/home/photos/.gem/ruby/1.9.1"]

$ ruby -ve 'Gem.use_paths("/home/photos/.gem/ruby/1.9.1"); p Gem.path; require "rack"'
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
["/home/photos/.gem/ruby/1.9.1"]
-e:1:in require': no such file to load -- rack (LoadError) from -e:1:in '

Many thanks for your listening.
=end

[wycats (Yehuda Katz)]

=begin
What exactly is the behavior you're expecting?
=end

[godfat (Lin Jen-Shin)]

=begin
Sorry for not being clear. What I would like to do is setting up
an rubygems environment that isn't affected by system gems.
I am doing this by setting gem path in ruby runtime, i.e.
Gem.use_paths' Then any later require' should search only paths
I assigned, but not any other path (e.g. system gem path).

This worked in 1.8 but not in 1.9.

I can setup gem path correctly in 1.9, but `require'
didn't follow the path it should follow. It still searched
the original path. Setting $GEM_PATH has no problem,
but I don't want to switch $GEM_PATH in runtime.

Thanks for your attention.
Cheers,

=end

[wycats (Yehuda Katz)]

=begin
@lin Carl Lerche and I are working on something along these lines right now that will be used by Rails 3, but available as a separate library. Hopefully much of that library, and the fixes we needed in order to achieve what we did, will be merged back into Rubygems. Our code is focused on allowing you to have a Rubygems environment in an application that has only the gems needed for that application (including dependencies). Our solution also doesn't require the rubygems runtime to run your application.

I posted some preliminaries at http://yehudakatz.com/2009/07/08/rails-bundling-revisited/

More details are forthcoming next week.
=end

[adamsalter (Adam Salter)]

=begin
I'm seeing this issue as well.
Would love to see some movement here...

I basically install all my gems without using 'sudo'... i.e. locally
and it seems that what used to be fine in Ruby 1.8 now doesn't work for 1.9

I 'gem install desired_gem' and get the error described above:
require 'desired_gem'
no such file to load -- desired_gem

of course the work around is to 'sudo gem install desired_gem' but this is less than ideal.
=end

[adamsalter (Adam Salter)]

=begin
As described above the other solution is to:
export GEM_PATH=/Users/adam/.gem/ruby/1.9.1

This is definately a bug in current rubygems (1.3.5) with ruby 1.9
=end

[adamsalter (Adam Salter)]

=begin
I've found that my suggestion above isn't completely reliable, I still get gems unable to be found in some cases.

The following seems to work 100% of the time:

export GEM_HOME=/opt/local/lib/ruby1.9/gems/1.9.1
export GEM_PATH=$GEM_HOME:/Users/adam/.gem/ruby/1.9.1

obviously if you do switch back to 1.8:

unset GEM_HOME
unset GEM_PATH
=end

[godfat (Lin Jen-Shin)]

=begin
I am not sure why, but calling Gem.source_index' would change Gem.path' 's value, and cause
`Gem.use_path' be a private method.

It seems that there's some magic in Gem.source_index,
and that modified Gem.path and cause this bug.

This is tested with trunk r24791.
=end

[naruse (Yui NARUSE)]

• Status changed from Open to Assigned
• Assignee set to drbrain (Eric Hodel)

=begin

=end

[vo.x (Vit Ondruch)]

=begin
I also reported this problem to RubyGems bug tracker: http://rubyforge.org/tracker/index.php?func=detail&aid=27216&group_id=126&atid=575
=end

[yugui (Yuki Sonoda)]

=begin
2009/7/13 Lin Jen-Shin [e-mail]:

$ gem which rack
(checking gem rack-1.0.0 for rack)
/home/photos/.gem/ruby/1.9.1/gems/rack-1.0.0/lib/rack.rb

$ ruby -ve 'gem "rack"'
ruby 1.9.1p129 (2009-05-12 revision 23412) [i686-linux]
internal:gem_prelude:234:in push_gem_version_on_load_path': Could not find RubyGem rack (>= 0) (Gem::LoadError)        from <internal:gem_prelude>:14:in gem'
       from -e:1:in `'

This is a bug of gem_prelude.rb. This will be fixed the next patch
level release of Ruby 1.9.1.
Now I'm trying releasing it within a week.

But the fixed version of gem_prelude works fine for only the default
path to user gem, i.e. ~user/.gem/ruby/1.9.1/
This lightweight version of gem loading mechanism does not have way to
reflect gemrc.
This is because gemrc is a YAML and YAML parser is too large to load
at Ruby starting. Do you have any idea?

-- Yuki Sonoda (Yugui)

=end

[godfat (Lin Jen-Shin)]

=begin
Good to know! It's a lot better than current state.
Many thanks!

For .gemrc's part, what I've come up now is:
a: Read .gem_preluderc with subset of YAML instead,
for example, only `key: value' is supported.

b: Read .gemrc and ignore all nested structure.

c: Change the fact that .gemrc using YAML,
break compatibility (if any)

I guess option "c" is the worst. "a" introduces another
rc file and duplicating some options with .gemrc,
annoying and confusing. "b" would surprise people
that some options are ignored, but I am not sure if
there're many options have nested structure?

cheers,
=end

[drbrain (Eric Hodel)]

• Tracker changed from Bug to Backport
• Status changed from Assigned to Closed

I think this is largely a bug of ruby 1.9.1's gem_prelude. Ruby 1.9.2's gem prelude works better, please reopen if you can reproduce the issue there.