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
In CHEF-2848 he supplies the following work around that seems to work:
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.