File.open("./lib/rubygems.rb", "w") do |f|
f.puts "module Kernel"
f.puts " def require_gem(file, version=nil)"
f.puts " autorequire = %s" % autorequire.inspect
f.puts " file = autorequire[file]"
f.puts " require(file) unless file.nil?"
f.puts " end"
f.puts "end"
end
Resulting in:
module Kernel
def require_gem(file, version=nil)
autorequire = {"activerecord"=>"active_record"}
file = autorequire[file]
require(file) unless file.nil?
end
end
Hmm, is this a good thing? If Ruby Gems replaces the require(), couldn't it be set to try the old require() when a Gem require fails? Just a thought.
James Edward Gray II
On Dec 8, 2004, at 10:57 AM, Mauricio Fernández wrote:
On Thu, Dec 09, 2004 at 01:22:30AM +0900, itsme213 wrote:
"Gavin Sinclair" <gsinclair@soyabean.com.au> wrote in message
Try:
require 'rubygems'
require 'progressbar'Will this allow nested (gem and non-gem) requires within 'progressbar' to
work?require 'foo' will always load the version from RubyGems, if you're
referring to that. Once you require 'rubygems', it overrides
Kernel.require and it is no longer possible to load the files in the
standard library dir, unless you use the GEM_SKIP env. variable.
"Jim Weirich" <jim@weirichhouse.org> wrote in message
If you don't care what version you get, just do a normal require.
Which would have gem's loadpath manager give me the latest gem-installed
version (assuming it is not in the current load path), true?
Regarding your GEM_PATH comment, I'm not sure what you are getting at.
GEM_PATH is for specifying where multiple gem repositories are locally
stored. Were you refering to RUBYOPT?
Yes. duh.
Thanks for the clarifications!
I didn't phrase that correctly. require 'foo' will load preferentially
the file in the gemdir (instead of the one in sitelibdir as usual).
On Thu, Dec 09, 2004 at 02:02:37AM +0900, James Edward Gray II wrote:
On Dec 8, 2004, at 10:57 AM, Mauricio Fernández wrote:
>On Thu, Dec 09, 2004 at 01:22:30AM +0900, itsme213 wrote:
>>
>>"Gavin Sinclair" <gsinclair@soyabean.com.au> wrote in message
>>>Try:
>>>
>>> require 'rubygems'
>>> require 'progressbar'
>>
>>Will this allow nested (gem and non-gem) requires within
>>'progressbar' to
>>work?
>
>require 'foo' will always load the version from RubyGems, if you're
>referring to that. Once you require 'rubygems', it overrides
>Kernel.require and it is no longer possible to load the files in the
>standard library dir, unless you use the GEM_SKIP env. variable.Hmm, is this a good thing? If Ruby Gems replaces the require(),
couldn't it be set to try the old require() when a Gem require fails?
Just a thought.
--
Hassle-free packages for Ruby?
RPA is available from http://www.rubyarchive.org/
"Jim Weirich" <jim@weirichhouse.org> wrote in message
If you don't care what version you get, just do a normal require.
itsme213 said:
Which would have gem's loadpath manager give me the latest gem-installed
version (assuming it is not in the current load path), true?
Yes.
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"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)
That makes a lot more sense to me. Thanks for setting me straight.
James Edward Gray II
On Dec 8, 2004, at 11:31 AM, Mauricio Fernández wrote:
require 'foo' will always load the version from RubyGems, if you're
referring to that. Once you require 'rubygems', it overrides
Kernel.require and it is no longer possible to load the files in the
standard library dir, unless you use the GEM_SKIP env. variable.Hmm, is this a good thing? If Ruby Gems replaces the require(),
couldn't it be set to try the old require() when a Gem require fails?
Just a thought.I didn't phrase that correctly. require 'foo' will load preferentially
the file in the gemdir (instead of the one in sitelibdir as usual).
Mauricio Fernández said:
Hmm, is this a good thing? If Ruby Gems replaces the require(),
couldn't it be set to try the old require() when a Gem require fails?
Just a thought.I didn't phrase that correctly. require 'foo' will load preferentially
the file in the gemdir (instead of the one in sitelibdir as usual).
Actually, this isn't accurate either.
Gems will only prefer the gem based file if the gem containing that file
has been activated.
Things that will activate a gem:
* an explicit require_gem
* requiring of a file not found in the current load path, but
can be found in a gem.
Once activated, files from the activated gem will be preferred. However,
files from unactivated gems will continue to be preferred from the
existing load path.
--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"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)
Wow. That's delightfully polite. I like it!
On Thu, 9 Dec 2004 03:18:04 +0900, Jim Weirich <jim@weirichhouse.org> wrote:
Mauricio Fernández said:
>> Hmm, is this a good thing? If Ruby Gems replaces the require(),
>> couldn't it be set to try the old require() when a Gem require fails?
>> Just a thought.
>
> I didn't phrase that correctly. require 'foo' will load preferentially
> the file in the gemdir (instead of the one in sitelibdir as usual).Actually, this isn't accurate either.
Gems will only prefer the gem based file if the gem containing that file
has been activated.Things that will activate a gem:
* an explicit require_gem
* requiring of a file not found in the current load path, but
can be found in a gem.Once activated, files from the activated gem will be preferred. However,
files from unactivated gems will continue to be preferred from the
existing load path.