Daniel Berger wrote:
<snip>
Ok, I think I've narrow this down a bit. The background to this is
that I've installed the library called "win32-file" via rubygems. That
library has a dependency on win32-file-stat, which in turn has a
dependency on windows-pr, which in turn has a dependency on windows-
api which in turn has a dependency on win32-api.
You with me so far? It's the win32-api gem (or lack thereof) that's
ultimately causing the issue.
You see, I'm using a custom built Ruby using VC++ 8.0, so I had to
uninstall win32-api (because the current binary gem I have out there
is incompatible with my runtime), so that rubygems defaults to the
win32-api I've built by hand and installed in Ruby's sitelibdir. At
least that's what I thought it would do.
And here's where it seems to get confused. Because one of the
dependencies itself has a dependency on win32-api, but I've removed
the win32-api gem, it dies instead of resorting to
gem_original_require as a last ditch effort.
I _think_ this can be resolved by rescuing Gem::LoadError in
custom_require.rb, but I'm still deciding how to proceed.
If anyone has any suggestion in the meantime, I'm all ears.
On second thought, this is a contract violation. I mean, if I say I want
"some_lib >= 0.2.0", but there's no gem and the version in sitelibdir is only
0.1.0, that could be trouble.
Another option would be a second, optional argument to the redefined
Kernel#require in custom_require.rb so that the method looks like:
def require(path, desparate=false)
...
if desperate
# Make a last ditch effort to find the lib in the standard libary
end
...
end
With the understanding that if 'desperate' is true, you're potentially violating
the gem versioning contract. Thoughts?
Regards,
Dan
_______________________________________________
Rubygems-developers mailing list
Rubygems-developers@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
