Patches item #26394, was opened at 2009-06-22 17:05 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=26394&group_id=126
Category: #gem and #require methods Group: None Status: Open Resolution: None Priority: 3 Submitted By: Vladimir Dobriakov (geekq) Assigned to: Nobody (None) Summary: Easier working on a fork of a gem Initial Comment: Hi, I already asked about the issue on a mailing list http://rubyforge.org/pipermail/rubygems-developers/2009-May/004665.html Now I have a concrete suggestion (patch). BTW, thanks for all the responses, I tried all the suggested workarounds in addition to workarounds that already came into my mind. Unfortunately they do not make my life less miserable. * editing source files to unshift $: can not be really used with a long chain of dependent gems where I would like to work on the gem in the middle of that chain - it would require editing the source code of other (depending) gems * 'ruby -I' can not be universally used if you do not call ruby directly; think of 'rake', 'script/server', ruby scripts called from shell scripts But after some research it seams, that there is a perfect solution only one step away. And it probably even already worked in the past. The documentation and implementation of Kernel#gem underwent lot of changes in the past and the documentation and the behavior seem not to match anymore. = Suggestion 1 My suggestion is to make the work on a private fork of a gem easy through environment variables by: 1. giving the developer version of a gem higher priority with RUBYLIB (already works as desired) 2. instructing rubygems through GEM_SKIP to ignore the version requirements in the Kernel#gem statements for particular gem (s. patch) = Alternative 2 Alternatively, if -I switch really works as promized in rdoc # In older RubyGems versions, the environment variable GEM_SKIP could be # used to skip activation of specified gems, for example to test out changes # that haven't been installed yet. Now RubyGems defers to -I and the # RUBYLIB environment variable to skip activation of a gem. and RUBYLIB does not work due a bug, then we should fix this bug. Or is that behaviour a feature and the documentation needs to be fixed? For me RUBYLIB does not skip the activation - I get "RubyGem version error:". I'm sure, I'm not the only one having big problems, other developers are also forced to do all possible sorts of dirty tricks to somehow help themselves [1] if respond_to? :gem begin begin gem 'locale', '>=2.0' rescue Gem::LoadError end rescue NoMethodError else LoadError end end Unfortunately, this particular one by my friend Masao does not work well. I would be glad to provide any clarification about usage scenarios bugging me so much and the motivation behind the patch. Best Regards, Vladimir [1] http://github.com/mutoh/gettext/blob/ee09a33de94a2699fb5d8b6894cb16a383a2963a/lib/gettext.rb#L16 ---------------------------------------------------------------------- You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=577&aid=26394&group_id=126 _______________________________________________ Rubygems-developers mailing list http://rubyforge.org/projects/rubygems [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
