Open shortdudey123 opened 7 years ago
Commenting out attribute :frozen?
cleans up 4 of the 6 warning lines, but i assume doing that breaks stuff elsewhere
attribute :default
is the other one that is causing the warnings
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.
this also helps a bit:
# get rid of Hashie / VariaModel warnings
Hashie.logger.level = Logger.const_get 'ERROR'
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"
}
Resolved the issue by upgrading Berkshelf to version 5.6.2.
Just upgraded Berkshelf to 5.6.4 but still have the warnings.
I'm in the same boat as @yourivdlans however, I'm on ChefDK 1.3.40 with Berkshelf 5.6.4,
Whatever code is causing these warnings to go to stdout instead of stderr is.. ungood.
It doesn't even respect ruby -w0
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.
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
$
I see this with the newest chef 13.6.4 and berkshelf 6.3.1
easily reproduced by installing/running knife solve -z <cookbook>
Using hashie (3.5.7, 3.5.5) and berkshelf (6.3.1) and using the following in my ruby file: require 'hashie/logger' Hashie.logger = Logger.new('/dev/null') Hashie.logger.level = Logger.const_get 'ERROR' Ridley::Logging.logger.level = Logger.const_get 'ERROR'
and class Response < ::Hashie::Mash disable_warnings end
But, still see the Warnings:
W, [2018-03-16T14:02:56.924739 #17419] 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 as a property. You can still access the key via the #[] method. W, [2018-03-16T14:02:56.924857 #17419] 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 as a property. You can still access the key via the #[] method. W, [2018-03-16T14:02:56.924891 #17419] 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 as a property. You can still access the key via the #[] method. W, [2018-03-16T14:02:56.927016 #17419] 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 as a property. You can still access the key via the #[] method. W, [2018-03-16T14:02:56.927061 #17419] 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 as a property. You can still access the key via the #[] method.
Can anyone suggest a fix/solution for the above ERROR please.
berks whatever | grep -v "You are setting a key that conflicts with a built-in method"
Can anyone suggest a fix/solution for the above ERROR please.
They are warnings not errors you can suppress them by invoking ruby as I described https://github.com/berkshelf/ridley/issues/366#issuecomment-313276433
# adjust path to match whichever ruby you are using and where the binary
# for berkshelf has been placed on disk
$ /opt/chefdk/embedded/bin/ruby -W0 /opt/chefdk/bin/berks
I updated the hashie in my gemfile to the newest (3.5.1) and am getting warnings now anytime i use the berks command
These warnings were added by Hashie: https://github.com/intridea/hashie/pull/381
Berkshelf uses ridley to talk to the chef server. Ridley appears to the be the one that is causing the warnings.
Moved from https://github.com/berkshelf/berkshelf/issues/1665