Warnings from Hashie gem

[shortdudey123]

I updated the hashie in my gemfile to the newest (3.5.1) and am getting warnings now anytime i use the berks command

W, [2017-01-31T17:36:52.072937 #15970]  WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-01-31T17:36:52.073207 #15970]  WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-01-31T17:36:52.073426 #15970]  WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-01-31T17:36:52.073604 #15970]  WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-01-31T17:36:52.161900 #15970]  WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#default defined in Hash. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-01-31T17:36:52.162095 #15970]  WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#default defined in Hash. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.

These warnings were added by Hashie:
hashie/hashie#381

Berkshelf uses ridley to talk to the chef server. Ridley appears to the be the one that is causing the warnings.

Moved from berkshelf/berkshelf#1665

[shortdudey123]

Commenting out attribute :frozen? cleans up 4 of the 6 warning lines, but i assume doing that breaks stuff elsewhere

[shortdudey123]

attribute :default is the other one that is causing the warnings

[kamaradclimber]

The issue is a bit painful since it logs on stdout.
A quick workaround is to change Hashie logger destination with:

require 'hashie/logger'
Hashie.logger = Logger.new(STDERR)

it does not solve the real issue though.

[atheiman]

this also helps a bit:

# get rid of Hashie / VariaModel warnings
Hashie.logger.level = Logger.const_get 'ERROR'

[DiegoYungh]

Windows 8.1 Single Language:

C:\Users\DiegoYungh> berks --version --format json
W, [2017-03-02T09:37:55.744632 #10200]  WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-03-02T09:37:55.745633 #10200]  WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-03-02T09:37:55.746634 #10200]  WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-03-02T09:37:55.746634 #10200]  WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#frozen? defined in Kernel. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-03-02T09:37:56.052838 #10200]  WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#default defined in Hash. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
W, [2017-03-02T09:37:56.053837 #10200]  WARN -- : You are setting a key that conflicts with a built-in method VariaModel::Attributes#default defined in Hash. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.
{
  "version": "5.6.0"
}

In my case I went to:
opscode\chefdk\embedded\lib\ruby\gems\2.3.0\gems\hashie-3.5.1\lib\hashie\logger.rb

and change L6
@logger ||= Logger.new(STDOUT)
to
@logger ||= Logger.new(nil)

I really don't want any logger messages now and since I'm using it inside vagrant is quite difficult for me to understand where should I block this logger or change it's level to ERROR.

now:

C:\Users\DiegoYungh> berks --version --format json
{
  "version": "5.6.0"
}

[MaRuifeng]

Resolved the issue by upgrading Berkshelf to version 5.6.2.

[yourivdlans]

Just upgraded Berkshelf to 5.6.4 but still have the warnings.

[qubitrenegade]

I'm in the same boat as @yourivdlans however, I'm on ChefDK 1.3.40 with Berkshelf 5.6.4,

[mikelindsey-okta]

Whatever code is causing these warnings to go to stdout instead of stderr is.. ungood.
It doesn't even respect ruby -w0

[majormoses]

There is nothing wrong with sending warnings to stdout like most things in technology it depends on what you are doing. That being said not respecting options is not good.

[majormoses]

I think that should be a -W0 though from what I see unless I am missing something:

$ ruby --help | grep -i -- -w
  -w              turn warnings on for your script
  -W[level=2]     set warning level; 0=silence, 1=medium, 2=verbose

example test:

$ cat /tmp/warnings.rb
#!/usr/bin/env ruby

warn('hello')

by default warnings are on:

$ /tmp/warnings.rb 
hello

turning off warnings:

$ ruby -W0 /tmp/warnings.rb
$

[jgoulah]

I see this with the newest chef 13.6.4 and berkshelf 6.3.1

easily reproduced by installing/running knife solve -z <cookbook>