[chef] Re: chef_gem vs gem_package vs the conundrum

[Matthew Moretti < >]

chef_gem already does call Gem.clear_paths.  You can see the source code here; all it does is subclass gem_package, call .run_action(:install)  on the resource so it runs at compile-time and the clears the gem paths.

If you need build-essential at compile-time as well, you can set node['build_essential']['compiletime'] to "true" and it the recipe will install those packages at compile-time as well.

-Matt Moretti

On Thu, Aug 23, 2012 at 3:51 PM, Leif Madsen < " target="_blank"> > wrote:

Howdy Chefs!

Today I ran into a bit of a conundrum with the way chef_gem and gem_package works, and I'm looking for feedback on either filing an issue or taking a stab at providing a patch, but wanted to see how others thought this should be implemented.

The issue I ran into (which appears that it'll be resolved in Chef 10.14.0 via CHEF-2848) is that ruby-shadow is required when using the user resource with the password attribute.

jtimberman seems to have provided a work around for the issue I ran into:

* chef_gem allows the use of the gem immediately, but requires build-essential to be installed, so installation fails due to it running prior to convergence
* gem_package allows build-essential to be installed, but fails due to it not being immediately available to the recipe (thereby requiring a second run)

In CHEF-2848 he supplies the following work around that seems to work:

```ruby
gem_package "ruby-shadow"

ruby_block "require shadow library" do
  block do
    Gem.clear_paths  # <-- Necessary to ensure that the new library is found
    require 'shadow' # <-- gem is 'ruby-shadow', but library is 'shadow'
  end
end
```

However, the issue I'm thinking, is that this isn't an issue just for ruby-shadow. For example, I have a recipe that wants mysql gem installed, so the same type of issue exists.

I could probably build an LWRP that added some sort of resource like gem_immediate or gem_awesome, or perhaps a change that added a new option to the gem_package that would cause it to execute Gem.clear_paths.

I'm curious if others think this is maybe the way gem_package should "just work", if an option should be added to it, or perhaps a third type of resource (not my favourite) for backwards compatibility. I suspect the option added to gem_package could be backward compatible if the default for the option was disabled.

Thoughts?

--
Leif Madsen
http://www.oreilly.com/catalog/asterisk