Asp Forum - several questions on using gems

David Garamond

11/20/2004 10:58:00 AM

1. If I write a Ruby library (including a gem package) for others, what
is the suggested way of require-ing other library? The gem version first
(like in Pickaxe II):

begin
require 'rubygems'
require_gem 'foolib'
rescue LoadError
require 'foolib'
end

Or the non-gem version first (like in Rake):

begin
require 'foolib'
rescue LoadError
require 'rubygems'
require_gem 'foolib'
end

And what's the rationale for each?

2. Has there been a schedule to include rubygems with official Ruby? I
guess it won't be in 1.8.2? (I do know Curt plans to include rubygems in
the 1.8.2 Windows installer).

3. When rubygems has been included with every Ruby installation, what
will be the standard way of requiring libraries? I hope it will be just:

require_gem 'foolib' # or perhaps require, whichever

What I wouldn't like is having to think to choose between 'require' or
'require_gem' each time I want to load a library. Or write some kind of
wrapper. So I'm guessing (again) that there will be some magic stuffs in
'require' and 'require_gem' to seamlessly choose the right stuffs?

Regards,
dave

5 Answers

Mauricio Fernández

11/20/2004 12:48:00 PM

On Sat, Nov 20, 2004 at 07:57:37PM +0900, David Garamond wrote:
> 1. If I write a Ruby library (including a gem package) for others, what
> is the suggested way of require-ing other library? The gem version first
> (like in Pickaxe II):
>
> begin
> require 'rubygems'
> require_gem 'foolib'
> rescue LoadError
> require 'foolib'
> end
>
> Or the non-gem version first (like in Rake):
>
> begin
> require 'foolib'
> rescue LoadError
> require 'rubygems'
> require_gem 'foolib'
> end
>
> And what's the rationale for each?

require_gem 'foolib' doesn't make much sense anymore: now RubyGems
incorporates the 'require hack', so just
require 'rubygems' # you might want to rescue LoadError here
require 'foolib'
should do. There is little gain in doing an "unqualified" require_gem
(i.e. without version information), and it won't work if the relevant
library wasn't installed with RubyGems... You can also leave the
require 'rubygems' out and set RUBYOPT=rubygems.

Note that once you have required 'rubygems', all subsequent
require 'foo' will use the libraries managed by RubyGems preferentially.
There is no easy way to reverse that, short of redefining require to
use the original method.

> 3. When rubygems has been included with every Ruby installation, what
> will be the standard way of requiring libraries? I hope it will be just:
>
> require_gem 'foolib' # or perhaps require, whichever
>
> What I wouldn't like is having to think to choose between 'require' or
> 'require_gem' each time I want to load a library. Or write some kind of
> wrapper. So I'm guessing (again) that there will be some magic stuffs in
> 'require' and 'require_gem' to seamlessly choose the right stuffs?

That wrapper is already there. You can just use require 'foolib' in
most cases.

--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyar...

David Garamond

11/21/2004 2:37:00 AM

Mauricio Fernández wrote:
> require_gem 'foolib' doesn't make much sense anymore: now RubyGems
> incorporates the 'require hack', so just

i see. thanks. should've gone and Use The Force (TM) first.

but i wonder why rubygems doesn't hack Kernel#require to accept version
requirements as well. that way i can forget all about Kernel#require_gem :-)

(I think Perl 6's 'use' will be able to pick module versions too).

Regards,
dave

Jim Weirich

11/21/2004 4:41:00 AM

On Saturday 20 November 2004 09:36 pm, David Garamond wrote:
> but i wonder why rubygems doesn't hack Kernel#require to accept version
> requirements as well. that way i can forget all about Kernel#require_gem

require works at a file level. require_gem works at a package level. There
is some confusion because (a) often packages often have the same name as
their main require file, and (b) rubygems allows you to specify a special
require file that is automatically required when the gem is loaded.

The difference is important because they are used differently. Every file
that uses (for example) the Builder::XmlMarkup class should include
'builder/xmlmarkup'. But the require_gem statement for builder should more
centralized. This is because you don't want to scatter explicit version
references throughout your code. It is better to keep them in one place
(more or less).

At least that's my current thinking on the topic.

--
-- Jim Weirich jim@weirichhouse.org http://onest...
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

David Garamond

11/21/2004 5:30:00 AM

Jim Weirich wrote:
> On Saturday 20 November 2004 09:36 pm, David Garamond wrote:
>
>>but i wonder why rubygems doesn't hack Kernel#require to accept version
>>requirements as well. that way i can forget all about Kernel#require_gem
>
> require works at a file level. require_gem works at a package level. There
> is some confusion because (a) often packages often have the same name as
> their main require file, and (b) rubygems allows you to specify a special
> require file that is automatically required when the gem is loaded.
>
> The difference is important because they are used differently. Every file
> that uses (for example) the Builder::XmlMarkup class should include
> 'builder/xmlmarkup'. But the require_gem statement for builder should more
> centralized. This is because you don't want to scatter explicit version
> references throughout your code. It is better to keep them in one place
> (more or less).
>
> At least that's my current thinking on the topic.

well, can't the rubygem's Kernel#require hack detect that when the
second (and third, ...) arguments are specified, then it's a gem
require, not a file require?

Regards,
dave

Jim Weirich

11/21/2004 7:58:00 AM

On Sunday 21 November 2004 12:30 am, David Garamond wrote:
> well, can't the rubygem's Kernel#require hack detect that when the
> second (and third, ...) arguments are specified, then it's a gem
> require, not a file require?

It's not a technical problem preventing the require hack from detecting it,
but a logical one. require and require_gem are two logically different
operations and therefore should have different names.

--
-- Jim Weirich jim@weirichhouse.org http://onest...
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

comp.lang.ruby

several questions on using gems

David Garamond

Mauricio Fernández

David Garamond

Jim Weirich

David Garamond

Jim Weirich

x Login to ForumsZone