[Rubygems-developers] [ rubygems-Patches-26394 ] Easier working on a fork of a gem

[noreply at rubyforge.org]

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