From: Josh Cheek <josh.cheek@...>
Date: 2010-01-31T03:21:46+09:00
Subject: Re: "require 'rubygems'" In Your Library/App/Tests Is Wrong?

--001636b2b118165dc3047e65d343
Content-Type: text/plain; charset=ISO-8859-1

I wonder how many people _don't_ use rubygems. What creates more work,
requiring rubygems so that people who don't want it don't have to use it, or
not requiring rubygems so that people who do want it have to keep putting
-rubygems when they load files?

Perhaps a compromise? If I am working on some gem that uses mechanize, I
could require it like this:

def require_gem( gem_name )
  begin
    require gem_name
  rescue LoadError
    require( begin GEM_MANAGER rescue 'rubygems' end )
    require gem_name
  end
end

require_gem 'mechanize'



This would have three benefits (assuming it is implemented by Ruby, and not
the gem maker)
1) it would stop people from having to require rubygems all the time, so
less work / issues (for newbies who don't know about this, figuring out they
need to require rubygems can take a while / be frustrating)
2) when you are writing a gem, you won't have to worry about how you are
loading the gems, because that decision is determined dynamically, so if a
user wants to use a different manager, they just change GEM_MANAGER, then
that same code uses rubygems on your system and in your tests, but uses
their gem manager on their system and their tests.
3) the end user doesn't get strongarmed into rubygems by gem creators, and
can easily switch between various managers by simply defining a single
constant


These are just thoughts, I don't like the idea of forcing things like this
on people either, but I also don't like the idea of creating headaches and
hoop jumping every time everyone else wants to use the code. If anyone with
more knowledge than me would like to critique the idea, I'd be interested to
know how viable it is.
-Josh

--001636b2b118165dc3047e65d343--