irb or ruby script does not look at gemrc config file #366

bitcoder opened this Issue Sep 4, 2012 · 7 comments


None yet

3 participants

bitcoder commented Sep 4, 2012

As can be seen bellow, the "gemrc" configuration file is not loaded in certain cases, namely when using "irb" or whenever invoking a ruby script in the console.
We have customized the gem path so the gems are going to be installed in a specific directory.
What i found out is that "gem" tool , uses the configuration file (/etc/gemrc in our case) for listing gems and installing them. Nevertheless, if invoking a script directly in the console (even explicitly requiring "rubygems") or irb, ruby, or rubygems in this case, does not load the /etc/gemrc config file.

[root@cte-dev-evl-cuke ~]# cat /etc/gemrc
gemhome: /opt/ruby

  • /opt/ruby
  • /opt/ptin/ruby
    [root@cte-dev-evl-cuke ~]# ls /opt/ruby/gems/ | grep sav
    [root@cte-dev-evl-cuke ~]#
    [root@cte-dev-evl-cuke ~]# gem list
    SF: PathSupport.initalize
    SF: do_configuration
    SF: load_file(/etc/gemrc)
    SF: load_file(/root/.gemrc)
    SF: PathSupport.initalize

*** LOCAL GEMS ***

savon (1.1.0)
[root@cte-dev-evl-cuke ~]#
[root@cte-dev-evl-cuke ~]# ruby -rubygems -e 'require "savon"'
SF: PathSupport.initalize
/usr/share/rubygems/rubygems/custom_require.rb:37:in require': cannot load such file -- savon (LoadError) from /usr/share/rubygems/rubygems/custom_require.rb:37:inrequire'
from -e:1:in `

[root@cte-dev-evl-cuke ~]#
[root@cte-dev-evl-cuke ~]# export GEM_PATH=/opt/ruby
[root@cte-dev-evl-cuke ~]# ruby -rubygems -e 'require "savon"'
[root@cte-dev-evl-cuke ~]#

Note that the "SF: " lines are debug that I added to rubygems source code, at the start of methods.

[root@cte-dev-evl-cuke rubygems]# pwd
[root@cte-dev-evl-cuke rubygems]# fgrep -r "SF:" *
rubygems/config_file.rb:puts "SF: load_file(#{filename})\n"
rubygems/path_support.rb:puts "SF: PathSupport.initalize\n"
rubygems/gem_runner.rb:puts "SF: do_configuration\n"
rubygems/custom_require.rb:#puts "SF: rubygems.require #{path}\n"
[root@cte-dev-evl-cuke rubygems]#

We're using rubygems 1.8.23 and Ruby 1.9.3p194.

evanphx commented Oct 6, 2012

You're correct, we don't load gemrc files normally. This is because doing so would heavily impact startup performance. Using the gemhome/gempath variables in the .gemrc are not recommended for this reason.

@evanphx evanphx closed this Oct 6, 2012
bitcoder commented Oct 8, 2012

Sorry, but this is a matter of being consistent and coherent - I mean,
If in some cases you load the gemrc configuration then it should always be
If the GEM_PATH environment is taken into consideration always, I don't see
why gemrc should not.
There is no performance drawback for processing the gemrc file; it's just a
small configuration file.
You either say that you support both the GEM_PATH environment variable and
the gemrc or you say that you dont.
You cannot have inconsistency or else users won't know exactly which one to
use. Btw, we prefer the configuration file approach.

On Sat, Oct 6, 2012 at 8:02 AM, Evan Phoenix notifications@github.comwrote:

You're correct, we don't load gemrc files normally. This is because doing
so would heavily impact startup performance. Using the gemhome/gempath
variables in the .gemrc are not recommended for this reason.

Reply to this email directly or view it on GitHub


This is hilarious... To deal with a performance issue from reading a 'configuration file' people introduce such a retarded mechanism such as environment variables :)

I wonder if the Iranians, Chinese and Russian have some sort of market for zero day exploits regarding this methods... I think I'm going to be rich :)

evanphx commented Oct 8, 2012

@bitcoder It's 2 fold: the time to load the YAML libraries and the time to parse the config file. At a time in the past, the .gemrc was always loaded and we decided that in order to improve startup time to remove it. Every little bit counts during startup since everything loads rubygems, so that was the reasoning. If you feel strongly about this, feel free to submit a pull request to add it, but be sure to profile startup and the effect it has.

@ketheriel There is no need to be rude, I was explaining the current behavior. The environment variables were there long before the config file, they were not a workaround.

bitcoder commented Oct 8, 2012

@evanphx, ok, if it has already been applied before in the past, can you get for me a copy of it patched or the patch itself? I can make the benchmarking if you want.
I understand your point of view but note that these kind of drawbacks are the ones that can be easily assumed. You would only read the file and parse it if the file exists... so you wouldn't need to require the YAML library and parse it everytime!
This seems reasonable to me while maitaining the coherence and correctness. What do you think?

bitcoder commented Oct 8, 2012

Parsing an YAML file is extremely fast, This was done in a VM so times are a lot slower than in a real one.

[root@cte-dev-evl-mm1 ~]# cat a.rb
#!/usr/bin/env ruby

require 'rubygems'
require 'yaml'


[root@cte-dev-evl-mm1 ~]# time ruby a.rb

real 0m0.027s
user 0m0.023s
sys 0m0.004s
[root@cte-dev-evl-mm1 ~]#

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment