# Chef 11.8 Dependency Question

**URL:** <https://discourse.chef.io/t/chef-11-8-dependency-question/4643>\
**Category:** Chef Infra (archive)\
**Created:** [November 1, 2013, 1:27am UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643 "2013-11-01T01:27:51Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![David\_Petzel](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/david_petzel/32/38_2.png) [@David\_Petzel](https://discourse.chef.io/u/David_Petzel)\
**Post date:** [November 1, 2013, 1:27am UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643/1 "2013-11-01T01:27:51Z")

</div>

TLDR - Chef 11.8.0 --\> chef-zero --\> Puma forces build tools, looking for a  
way to avoid that

Seemingly out of nowhere (between 08:40 and 17:20 pacific), our CI process  
for testing cookbooks is no longer worker. The error I’m seeing is:

```auto
[2013-10-31T17:38:56-07:00] FATAL: Gem::Installer::ExtensionBuildError:
chef_gem[minitest-chef-handler] (minitest-handler::default line 13) had an
error: Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem
native extension.

        /opt/chef/embedded/bin/ruby extconf.rb
creating Makefile
10.42.4.121
make
compiling puma_http11.c
make: gcc: Command not found
make: *** [puma_http11.o] Error 127

```

My gem skillz are not top notch, but I believe after digging through debug  
level logging is that in 11.6.x puma was a development requirement, but not  
a runtime requirement, so it was never installed on our nodes

Now with 11.8.0, there is a dependency on chef-zero, which has a runtime  
dependency on Puma, so now it is trying to install it.

Where I get confused is that I’m running 10.26.0, so its unclear to me how  
that new dependency chain might affect me, but the timing is hard to ignore.

So my question is does that make sense, or am I way off base here? If it  
does make sense what options do I have to not have to have build tools on  
every box I want to install minitest-chef-handler?

---

<div class="post-metadata">

**Author:** ![Serdar\_Sutay](https://avatars.discourse-cdn.com/v4/letter/s/c68b51/32.png) [@Serdar\_Sutay](https://discourse.chef.io/u/Serdar_Sutay)\
**Post date:** [November 1, 2013, 3:58am UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643/2 "2013-11-01T03:58:33Z")

</div>

Looks like minitest-chef-handler has below dependency on Chef:

gem.add\_dependency('chef', '\>= 10.12.0')

If you have a Gemfile by which you are controlling your environment you can add:

gem 'chef', '~\>10.26'

to it which should move you to Chef 10 and will resolve the issue.

Hope this helps. If not, it would help if you can give a little bit  
more details about your CI process of testing cookbooks.

Thanks,  
-- Serdar

On Thu, Oct 31, 2013 at 6:27 PM, David Petzel [davidpetzel@gmail.com](mailto:davidpetzel@gmail.com) wrote:

> TLDR - Chef 11.8.0 --\> chef-zero --\> Puma forces build tools, looking for  
> a way to avoid that
> 
> Seemingly out of nowhere (between 08:40 and 17:20 pacific), our CI process  
> for testing cookbooks is no longer worker. The error I'm seeing is:
> 
> ```auto
> [2013-10-31T17:38:56-07:00] FATAL: Gem::Installer::ExtensionBuildError:
> chef_gem[minitest-chef-handler] (minitest-handler::default line 13) had an
> error: Gem::Installer::ExtensionBuildError: ERROR: Failed to build gem
> native extension.
> 
> /opt/chef/embedded/bin/ruby extconf.rb
> creating Makefile
> 10.42.4.121
> make
> compiling puma_http11.c
> make: gcc: Command not found
> make: *** [puma_http11.o] Error 127
> 
> ```
> 
> My gem skillz are not top notch, but I believe after digging through debug  
> level logging is that in 11.6.x puma was a development requirement, but not  
> a runtime requirement, so it was never installed on our nodes
> 
> Now with 11.8.0, there is a dependency on chef-zero, which has a runtime  
> dependency on Puma, so now it is trying to install it.
> 
> Where I get confused is that I'm running 10.26.0, so its unclear to me how  
> that new dependency chain might affect me, but the timing is hard to ignore.
> 
> So my question is does that make sense, or am I way off base here? If it  
> does make sense what options do I have to not have to have build tools on  
> every box I want to install minitest-chef-handler?

---

<div class="post-metadata">

**Author:** ![David\_Petzel](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/david_petzel/32/38_2.png) [@David\_Petzel](https://discourse.chef.io/u/David_Petzel)\
**Post date:** [November 1, 2013, 11:33am UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643/3 "2013-11-01T11:33:49Z")

</div>

Thanks Serdar,  
Unfortunately, I don't think the Gemfile will help in this case, but let me  
give you a little more background on the CI process.

Upon commit to master to a specific cookbooks git repo the following  
occurs:

- Cookbook source is uploaded to a dedicated testing org on the chef server
- A VM is launched and bootstrapped with 10.26.0 omnibus
- The run list will include the minitest-handler-cookbook, as well as the  
applicable test role/recipe that is specific to that cookbook.
- When it passes, its then uploaded to the prod org

So given that we are simply bootstrapping a 10.26.0 client and kicking off  
a run, I'm not clear how/where I'd introduce a Gemfile to my environment,  
but I'm happy to try it if you can let me know I'd do in my situation.

From what I've been able to debug, I'd be surprised if others are not  
seeing this issue as the dependency issues seems to be come from upstream  
(unless of course folks make it a standard practice to have build tools on  
their CI nodes)?

On Thu, Oct 31, 2013 at 11:58 PM, Serdar Sutay [serdar@opscode.com](mailto:serdar@opscode.com) wrote:

> Looks like minitest-chef-handler has below dependency on Chef:
> 
> gem.add\_dependency('chef', '\>= 10.12.0')
> 
> If you have a Gemfile by which you are controlling your environment you can add:
> 
> gem 'chef', '~\>10.26'
> 
> to it which should move you to Chef 10 and will resolve the issue.
> 
> Hope this helps. If not, it would help if you can give a little bit more details about your CI process of testing cookbooks.

---

<div class="post-metadata">

**Author:** ![John\_Keiser3](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/john_keiser3/32/428_2.png) [@John\_Keiser3](https://discourse.chef.io/u/John_Keiser3)\
**Post date:** [November 1, 2013, 5:16pm UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643/4 "2013-11-01T17:16:36Z")

</div>

Another thing you can do is directly install chef 10.26.0 on your  
node--then minitest-handler will just pick that instead of jumping to 11.

As far as the compiling dependency, many folks won't hit that because they  
install chef with omnibus--no build tools involved, just install the  
.deb/.rpm/etc.

puma was chosen because it was the only webserver I could find that works  
everywhere Chef is supported (all Ruby versions and all platforms). This  
included webrick (though I can't remember which platform/ruby version it  
failed on). To see if I can help with this, I'll take another pass at  
finding a pure Ruby one with those characteristics, or some if statements I  
can use 🙂

On Fri, Nov 1, 2013 at 4:33 AM, David Petzel [davidpetzel@gmail.com](mailto:davidpetzel@gmail.com) wrote:

> Thanks Serdar,  
> Unfortunately, I don't think the Gemfile will help in this case, but let  
> me give you a little more background on the CI process.
> 
> Upon commit to master to a specific cookbooks git repo the following  
> occurs:
> 
> - Cookbook source is uploaded to a dedicated testing org on the chef server
> - A VM is launched and bootstrapped with 10.26.0 omnibus
> - The run list will include the minitest-handler-cookbook, as well as the  
> applicable test role/recipe that is specific to that cookbook.
> - When it passes, its then uploaded to the prod org
> 
> So given that we are simply bootstrapping a 10.26.0 client and kicking off  
> a run, I'm not clear how/where I'd introduce a Gemfile to my environment,  
> but I'm happy to try it if you can let me know I'd do in my situation.
> 
> From what I've been able to debug, I'd be surprised if others are not  
> seeing this issue as the dependency issues seems to be come from upstream  
> (unless of course folks make it a standard practice to have build tools on  
> their CI nodes)?
> 
> On Thu, Oct 31, 2013 at 11:58 PM, Serdar Sutay [serdar@opscode.com](mailto:serdar@opscode.com) wrote:
> 
> > Looks like minitest-chef-handler has below dependency on Chef:
> > 
> > gem.add\_dependency('chef', '\>= 10.12.0')
> > 
> > If you have a Gemfile by which you are controlling your environment you can add:
> > 
> > gem 'chef', '~\>10.26'
> > 
> > to it which should move you to Chef 10 and will resolve the issue.
> > 
> > Hope this helps. If not, it would help if you can give a little bit more details about your CI process of testing cookbooks.

---

<div class="post-metadata">

**Author:** ![David\_Petzel](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/david_petzel/32/38_2.png) [@David\_Petzel](https://discourse.chef.io/u/David_Petzel)\
**Post date:** [November 1, 2013, 5:20pm UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643/5 "2013-11-01T17:20:04Z")

</div>

Thanks John,  
So I'm not sure I following your comment. I did install via omnibus, so I  
don't have build tools installed, which is where the issue seems to stem  
from. Here is a GIST of what I'm seeing.

> <https://gist.github.com/dpetzel/7268621>

Even when attempting to install manually I'm hitting that error.

On Fri, Nov 1, 2013 at 1:16 PM, John Keiser [jkeiser@opscode.com](mailto:jkeiser@opscode.com) wrote:

> Another thing you can do is directly install chef 10.26.0 on your  
> node--then minitest-handler will just pick that instead of jumping to 11.
> 
> As far as the compiling dependency, many folks won't hit that because they  
> install chef with omnibus--no build tools involved, just install the  
> .deb/.rpm/etc.
> 
> puma was chosen because it was the only webserver I could find that works  
> everywhere Chef is supported (all Ruby versions and all platforms). This  
> included webrick (though I can't remember which platform/ruby version it  
> failed on). To see if I can help with this, I'll take another pass at  
> finding a pure Ruby one with those characteristics, or some if statements I  
> can use 🙂
> 
> On Fri, Nov 1, 2013 at 4:33 AM, David Petzel [davidpetzel@gmail.com](mailto:davidpetzel@gmail.com)wrote:
> 
> > Thanks Serdar,  
> > Unfortunately, I don't think the Gemfile will help in this case, but let  
> > me give you a little more background on the CI process.
> > 
> > Upon commit to master to a specific cookbooks git repo the following  
> > occurs:
> > 
> > - Cookbook source is uploaded to a dedicated testing org on the chef  
> > server
> > - A VM is launched and bootstrapped with 10.26.0 omnibus
> > - The run list will include the minitest-handler-cookbook, as well as the  
> > applicable test role/recipe that is specific to that cookbook.
> > - When it passes, its then uploaded to the prod org
> > 
> > So given that we are simply bootstrapping a 10.26.0 client and kicking  
> > off a run, I'm not clear how/where I'd introduce a Gemfile to my  
> > environment, but I'm happy to try it if you can let me know I'd do in my  
> > situation.
> > 
> > From what I've been able to debug, I'd be surprised if others are not  
> > seeing this issue as the dependency issues seems to be come from upstream  
> > (unless of course folks make it a standard practice to have build tools on  
> > their CI nodes)?
> > 
> > On Thu, Oct 31, 2013 at 11:58 PM, Serdar Sutay [serdar@opscode.com](mailto:serdar@opscode.com)wrote:
> > 
> > > Looks like minitest-chef-handler has below dependency on Chef:
> > > 
> > > gem.add\_dependency('chef', '\>= 10.12.0')
> > > 
> > > If you have a Gemfile by which you are controlling your environment you can add:
> > > 
> > > gem 'chef', '~\>10.26'
> > > 
> > > to it which should move you to Chef 10 and will resolve the issue.
> > > 
> > > Hope this helps. If not, it would help if you can give a little bit more details about your CI process of testing cookbooks.

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [November 1, 2013, 5:33pm UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643/6 "2013-11-01T17:33:43Z")

</div>

On Friday, November 1, 2013 at 10:20 AM, David Petzel wrote:

> Thanks John,  
> So I'm not sure I following your comment. I did install via omnibus, so I don't have build tools installed, which is where the issue seems to stem from. Here is a GIST of what I'm seeing.
> 
> [minitest-chef-handler/puma whoas · GitHub](https://gist.github.com/dpetzel/7268621)
> 
> Even when attempting to install manually I'm hitting that error.  
> Rubygems, by default, will upgrade every gem it possibly can when installing a new gem. This means that if any “chef plugin” kind of project specifies a dependency on Chef, rubygems will try to upgrade chef when you install it. I don’t know exactly when the option was added, but newish versions of rubygems have a `—conservative` option that should disable that behavior. I’d need to look more in-depth to see how you should use this with the chef\_gem or gem\_package resources, but it should work if you give that option as a string to the options parameter.

In the bigger picture, it may be best if plugins do not specify a dependency on Chef. The downside to that is plugins can’t specify a minimum version of chef they support. I don’t have a good solution for that right now.

--  
Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![Mike](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/mike/32/18_2.png) [@Mike](https://discourse.chef.io/u/Mike)\
**Post date:** [November 1, 2013, 5:39pm UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643/7 "2013-11-01T17:39:55Z")

</div>

> In the bigger picture, it may be best if plugins do not specify a  
> dependency on Chef. The downside to that is plugins can’t specify a minimum  
> version of chef they support. I don’t have a good solution for that right  
> now.  
> I recently ran into this very problem.

I've since changed my plugin to have Chef version as a development  
dependency instead of a runtime one, since the plugin is only going to run  
under Chef anyways, so the runtime is somewhat guaranteed to be in a Chef  
version.

The problem arises when the plugin is targeted towards a specific Chef  
version(s), and that's currently the only way to constrain things. However,  
if you're constraining on a specific X.Y.Z version of Chef, you should be  
ok. It's where 11.8.0 introduces new dependencies that were not previously  
there - that's where we're all getting stuck.

-M

On Fri, Nov 1, 2013 at 1:33 PM, Daniel DeLeo [dan@kallistec.com](mailto:dan@kallistec.com) wrote:

> On Friday, November 1, 2013 at 10:20 AM, David Petzel wrote:
> 
> Thanks John,  
> So I'm not sure I following your comment. I did install via omnibus, so I  
> don't have build tools installed, which is where the issue seems to stem  
> from. Here is a GIST of what I'm seeing.
> 
> [minitest-chef-handler/puma whoas · GitHub](https://gist.github.com/dpetzel/7268621)
> 
> Even when attempting to install manually I'm hitting that error.
> 
> Rubygems, by default, will upgrade every gem it possibly can when  
> installing a new gem. This means that if any “chef plugin” kind of project  
> specifies a dependency on Chef, rubygems will try to upgrade chef when you  
> install it. I don’t know exactly when the option was added, but newish  
> versions of rubygems have a `—conservative` option that should disable that  
> behavior. I’d need to look more in-depth to see how you should use this  
> with the chef\_gem or gem\_package resources, but it should work if you give  
> that option as a string to the options parameter.
> 
> In the bigger picture, it may be best if plugins do not specify a  
> dependency on Chef. The downside to that is plugins can’t specify a minimum  
> version of chef they support. I don’t have a good solution for that right  
> now.
> 
> --  
> Daniel DeLeo

---

<div class="post-metadata">

**Author:** ![David\_Petzel](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/david_petzel/32/38_2.png) [@David\_Petzel](https://discourse.chef.io/u/David_Petzel)\
**Post date:** [November 1, 2013, 5:49pm UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643/8 "2013-11-01T17:49:32Z")

</div>

I think I'm fairly clear on the short term workaround (using the —conservative  
flag) however I wonder how many plugins out there do this, and thus are  
subject to this issue now that 11.8 has been released. Is it acceptable  
that 11.8 introduces a dependency on a gem that requires build tools? I ask  
because I'm not sure what expectations.

> It's where 11.8.0 introduces new dependencies that were not previously  
> there - that's where we're all getting stuck.
> 
> -M

---

<div class="post-metadata">

**Author:** ![kallistec](https://sea2.discourse-cdn.com/flex016/user_avatar/discourse.chef.io/kallistec/32/23_2.png) [@kallistec](https://discourse.chef.io/u/kallistec)\
**Post date:** [November 1, 2013, 5:49pm UTC](https://discourse.chef.io/t/chef-11-8-dependency-question/4643/9 "2013-11-01T17:49:57Z")

</div>

On Friday, November 1, 2013 at 10:39 AM, Mike wrote:

> The problem arises when the plugin is targeted towards a specific Chef version(s), and that's currently the only way to constrain things. However, if you're constraining on a specific X.Y.Z version of Chef, you should be ok. It's where 11.8.0 introduces new dependencies that were not previously there - that's where we're all getting stuck.  
> That’s the trigger that exposes the issue, but there are a number of ways that this could happen. Chef depends on a handful of gems with C extensions, and if any of these were to release a new version that matched Chef’s version constraints, then rubygems would attempt to upgrade them when installing anything that depends on Chef. To borrow (and butcher) a phrase from Allspaw, both conditions are necessary and only jointly sufficient for this problem to occur.

It’s also pretty troubling that you could unknowingly get upgraded to a newer version of chef (including a major version update) when you only wanted to install a test framework.

> -M

--  
Daniel DeLeo