You can clone with
HTTPS or Subversion.
lib/fog/bin/libvirt.rb, lib/fog/bin/virtual_box.rb and lib/fog/bin/vmfusion.rb are using rubygems without explicitly require it.
Please add the needed require 'rubygems'
@bigon While this is sometime necessary, it should be the exception rather than the rule. Check out Why "require 'rubygems'" Is Wrong for more information on this.
@hecticjeff Even if you are using stuff like this: Gem::Specification::find_by_name() ? I mean, using this function already defeat the "The system I use to manage my $LOAD_PATH is not your library / app / tests concern." point, isn't it?
It's a real question, since I'm not ruby developer, I'm just packaging ruby-fog for debian actually
Yes I suppose this is something of an edge case as fog uses rubygems internally. The situation gets muddier because ruby 1.9 comes with rubygems, so there is no need to require it explicitly, whereas ruby 1.8 it needs to be required.
I'm not sure what the best solution is here, you should be able to get your package working by setting RUBYOPT='rubygems' in the environment, but you're right, it seems like something fog should do.
I would say its a bug, but I don't think requiring rubygems is necessarily the right fix. I think that using the Gem::Specification stuff is the wrong approach. I think that it should probably just use a require and (if necessary) rescue the load error. That then leaves it up to require to "do the right thing" based on the user setup. So these files should probably be changed to do that instead.
I'm kind of fond of something like this
rescue LoadError => e
retry if require('rubygems')
It'll retry loading with rubygems and if that still fails it'll raise an exception
@estonfer - yeah, that seems like it could help. I don't want to have to repeat something like that everywhere though, if it can be avoided.
The problem has migrated to lib/fog/vmfusion/compute.rb (and the like) instead of still being in the bin files, fwiw.
rescue/retry when loading gems (possibly without rubygems)