You should take CHEF-669 too as this is all the same discussion.
> We're going to end up adding or remove the rubygems require somewhere, but it in source, or packaging. I personally feel the way rubgems handles loading libraries makes it source intrusive and inappropriate as a default, but I'm an SA first and a ruby developer/user second.
>
> I assume then that your rubygem-* RPM packages are simply packaged up copies of the gems, and the libraries are not installed anywhere in the Ruby $LOAD_PATH and this is why you need require rubygems?
>
Correct. The dependencies are rubygem-* packages packaged from gems. Ohai is packaged from source and needs rubygems loaded to find the dependencies.
> I think the solution is that we should remove the require from all the source, and add it where appropriate as part of the Rake task for building the gem. This keeps the source clean, satisfies the gem, and if my above assumption is correct, should make your fedora submission easier.
>
This is effectively the way it is now. No require rubygems in source repo, and in building the gem the generated bin/ohai wrapper loads it correctly.
>> * doesn't work from the git checkout with the dependencies installed as gems eg:
>
> I think this development only edge case is worth WONTFIX. If you do install as a gem from here, it should work fine via the wrapper, no? And whatever else you may have installed such as chef-client should also be installed via ruby gems and function similarly, no?
Just to make sure we are on the same page: for local ohai development I have to run
ruby -rrubygems bin/ohai
so the mixlib/systemu/extlib gems get picked up properly. Hardly a big deal I know.
To sum up: if the current way this is done in ohai, with no 'require rubygems' in the source, is optimal for the project, then ignore me and my packaging edge case and close as WONTFIX. I'll happily patch it in the rpm packages. Though at least I can justify the patch since we had this discussion 
Thanks for your time.
Could be used to resolve
OHAI-119as well?