require rubygems in bin/ohai

Could be used to resolve OHAI-119 as well?

> * i'll have to patch it to load rubygems for my fedora submission

Is this because you have no fedora packages for gem dependencies that you aren't going to package first?

If so, how do you handle making sure those dependencies are installed?

Hi!

No I've packaged ohai's deps as rubygem-* packages which have been accepted upstream (OHAI-118). The current package for ohai, which is being reviewed, depends on them.

My need to patch is better outlined here: https://www.redhat.com/archives/fedora-packaging/2009-October/msg00091.html to which unfortunately I received little response (though the reviewer for ohai said he'd be fine with whatever). The current choice I'm going with is b) as it's the simplest. As opposed to adding a bunch more packages to Fedora which don't add much value as they don't mind rubygems like Debian does. Plus doing the Chef package in this manner is far easier than convincing other maintainers to alter their packages to produce versions that don't require rubygems.

In typing this that's probably more info than you wanted

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?

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.

> * 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?

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.

On Wed, Nov 4, 2009 at 7:52 PM, Matthew Kent (JIRA)
<sysadmin@opscode.com> wrote:

> 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.

Yeah, I think that's reasonable and we as developers can live with
that if we want to run ohai out of the source tree without
building/installing a gem.

> 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

Oh hmm. I guess I had some lines crossed and was assuming you were
going to package ohai from gem as well which would mean the rake gem
task would get you what you needed. I don't know rpm packaging that
well, so I don't know if there's an automated patch system like dpatch
or quilt in debian.

> http://github.com/mdkent/ohai/commit/0062e57059d91630c83e79e28341fc088932e3d4

That's super creative and awesome edge-caseness. However, we're adding a lot of work-arounds to a ruby library for a particular packaging tool. When weighing if it is better to add to the source or add to the packaging, I'm feeling it is more appropriate to add to the packaging. We're going to have to add something somewhere, that feels the most organized.

If you're packaging ohai as a library for chef, and both are packaged as gems, chef should require rubygems somewhere on its own, which is what makes me feel it isn't appropriate to put effort into having Rake add a require in when building a gem. Your gem wrapper for the binary, assuming there is one because rubygems is all for support multiple gem versions and needs to sneak in the code to activate the right version, should require rubygems just fine when you're running ohai directly.

If this isn't the case and the solution to your packaging problem doesn't seem obvious or reasonable simple, I encourage you to email/irc me and I'll help you think it out. As we've discussed, I'm going to recommend WONTFIX.

We're going to go ahead and apply this patch. Yes it's more code just to work around packaging, which is bad, but the benefit of being able to run the ohai binary from source checkout is worth it.

set resolution to fixed.

Patch applied and pushed to master