several questions on using gems

[David Garamond]

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

 

[Mauricio Fernández]

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.

 

[David Garamond]

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]

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.

 

[David Garamond]

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]

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.