Berks install warnings after ChefDK 0.10

Chef Infra (archive)
1

After updating my OS X and Ubuntu machine to ChefDK 0.10 I’ve started to see the following warning outputs when using the ChefDK provided Berkshelf:

$ berks install
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/httpclient-2.6.0.1/lib/httpclient/webagent-cookie.rb:458: warning: already initialized constant HTTPClient::CookieManager
/opt/chefdk/embedded/lib/ruby/gems/2.1.0/gems/httpclient-2.6.0.1/lib/httpclient/cookie.rb:8: warning: previous definition of CookieManager was here
Resolving cookbook dependencies...
....

They seem to be harmless but I don’t know why that happens. I’ve tried removing my ~/.chefdk/gems directory, but the error is coming from /opt/chefdk.

We use Bundler for all our cookbooks, so when I execute bundle exec berks install I don’t see those errors.

Thank you in advance,
Arthur Maltson

2

Arthur,

Been getting the same message as well. Talked with a fellow at Chef a few days back and he said it was nothing to worry about, just a known “annoyance”.

Cheers,
Robert Stinnett

3

We contributed a fix for this in the upstream library and it recently was merged:

But it doesn’t look like it’s been released yet based on the github history for that project.

4

@kallistec it doesn’t look like a 2.6.0.2 was released. Do you think it’s safe to upgrade Berkshelf to 2.7.1 of httpclient? Thanks!

5

It's probably fine, but Berks is now checking in the Gemfile.lock and also has a somewhat strict version constraint on httpclient: https://github.com/berkshelf/berkshelf/blob/a05e39202aebbb239e887a479c984b23167b5925/berkshelf.gemspec#L40

All the Chef employees are gathering for meetings this week, so response times to pull requests and such might be delayed but you can kick off the process by updating the the gemspec and Gemfile.lock and submitting a pull request. This will run all the tests in travis so we should know if there's any problems with the new version.

6

Thanks, I'll send a PR from home (can't contribute from work).

I have a local fork of Berkshelf we're using which sets the default solver to the new Ruby based solver, so I'll make the update there too. Thanks!

Edit: I just tried this out, it looks like berkshelf-api-client also has a strict version for httpclient. I might just fork httpclient internally and release a 2.6.0.2 with the merged PR.

7

That is also in master now, so you might look at using that instead of your fork when the next release comes out: Add a new `solver` Berksfile DSL option by martinb3 · Pull Request #1482 · berkshelf/berkshelf · GitHub

8

Hmm I saw that, but it'd be nice if there was a way to globally use the Ruby solver automatically rather than updating every Berksfile. Is that something that could be done in the ~/.berkshelf/config.json or something?

9

I don't think it's currently written to work that way, but I think it would be easy to add this feature. Personally I don't like it because everyone on your team has to replicate this config or else they get different behaviors than you do, so I think adding a few characters in your berksfile is worth the trouble. But if you feel the tradeoffs are worth it, it's your call IMO.

10

I guess that's why I just changed it in the Berkshelf gem itself. Also, we have workstation cookbooks that keep everyone in sync, so a property in the ~/.berkshelf/config.json would be useful as well.

I just find the Ruby solver is so much better and actually resolves dependencies, whereas the original gecode dep solver keeps failing. There seems to be an issue that cropped up a month ago when one has a private and public supermarket in their Berksfile. The Ruby solver doesn't have any issues with it.