[chef] chef_gem vs gem_package vs the conundrum

[Leif Madsen < >]

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