/etc/env.d/10rubygems sets RUBYOPT="-rauto_gem", which seems to be a hack so that people don't have to say `require "rubygems"`. A very, very common pattern for Ruby systems is to have a stable system Ruby and then install custom ones using rvm/rbenv for production. This strange setting gets in the way of expected behavior. Reproducible: Always Steps to Reproduce: 1. Install ruby1.8 2. Install any non-Gentoo Ruby (e.g. https://github.com/sstephenson/rbenv/ ) 3. The new one will fail until you `unset RUBYOPT` Actual Results: % echo $RUBYOPT -rauto_gem % which ruby /home/rking/.rbenv/shims/ruby % ruby -v ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux] % ruby -e 1 /home/rking/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- auto_gem (LoadError) from /home/rking/.rbenv/versions/1.9.3-p194/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require' [1] 23078 exit 1 ruby -e 1 I'm not 100% what the right fix is. I know that the ruby1.9 package doesn't have this problem, but for a good while we're still going to see 1.8 installed, and this makes Gentoo look like they don't know what Ruby is doing. My thinking is that this same functionality should be done as a patch to the C, not to the environment (which is, by the way, what the newer Ruby source does: https://github.com/ruby/ruby/blob/trunk/ruby.c#L1370 Any thoughts?
It's a hack, we know. It was put in place at a time where rubygems was nowhere near the integration we see today. But it is documented and people might rely on it, and given ruby 1.8's rather short remaining life span, we're not going to change it. It will be removed together with 1.8 when it loses security support. Until then, you've already mentioned one workaround for custom ruby installations.
(In reply to comment #0) > A very, very common pattern for Ruby systems is to have a stable system Ruby > and then install custom ones using rvm/rbenv for production. This strange > setting gets in the way of expected behavior. Actually, we try to obsolete this pattern by providing support for multiple rubies out of the box. If this doesn't work for you then please let us know what we can improve there instead of relying on stuff like rvm.
Alex and Hans, I appreciate the responses. Let me address a few things: 1) I don't think 1.8 is quite on its way out. Many working systems use it, and since Ruby does not place as high a value on backwards compatibility as other languages, it's not always as easy as installing a new version and trusting that everything will work. Great example: emerge ruby; ← What do you get? 1.8. So the current Gentoo release is currently propagating even more 1.8 installations. It's not yet time to consider the version good as gone. 2) It's nice that Gentoo supports a few versions easily, but that's far from covering all solutions. One might develop an application on a Gentoo box then deploy to a host they have less control over. It's unwise to mismatch even patchlevel differences in versions, so you end up putting rbenv on both machines and locking it all together as airtight as possible. Or it could be the other way, where development is happening on some crippled environment, like somebody's Windows machine, then they're deploying to a Gentoo server. So you use rbenv on both sides to minimize the differences. Or, in another scenario, you don't have root access so you can't change system versions. So you use rbenv. 3) I don't really see the risk of adding rb_require("rubygems"); to the 1.8 C. It will do exactly the same thing as RUBYOPT does but without the uncooperativeness with other versions. Thanks! —☈
(In reply to comment #3) > 1) I don't think 1.8 is quite on its way out. Many working systems use it, > and since Ruby does not place as high a value on backwards compatibility as > other languages, it's not always as easy as installing a new version and > trusting that everything will work. We'll have until summer next year, at that time we'll re-assess how feasible it is, but I'm sure we'll start pushing it out when there is no longer security support for it. > Great example: emerge ruby; ← What do you get? 1.8. So the current Gentoo > release is currently propagating even more 1.8 installations. It's not yet > time to consider the version good as gone. Actually you'll get 1.9 now. But it's true that our eselect still prefers 1.8 to be the primary ruby. We'll switch that once a good set of packages is stable for ruby19, probably somewhere this fall. > 3) I don't really see the risk of adding rb_require("rubygems"); to the 1.8 > C. It will do exactly the same thing as RUBYOPT does but without the > uncooperativeness with other versions. It takes away the ability to turn this off. I know we do this in some cases in ebuilds. In any case I'm happy to review a patch, provided that it also considers all other use of RUBYOPT in our tree.
