New version of hashie breaks omniauth #391

Closed
kbrock opened this Issue Jan 31, 2017 · 23 comments

Comments

Projects
None yet
7 participants
@kbrock

kbrock commented Jan 31, 2017

The new version of hashie is blowing up our build on travis:

Bundler::GemRequireError: There was an error while trying to load the gem 'omniauth-google-oauth2'.
Gem Load Error is: uninitialized constant Hashie::Extensions::RubyVersionCheck::ClassMethods::RubyVersion
Backtrace for gem load error is:

hashie-3.5.0/lib/hashie/extensions/ruby_version_check.rb:10:in `with_minimum_ruby'
hashie-3.5.0/lib/hashie/array.rb:8:in `<class:Array>'
hashie-3.5.0/lib/hashie/array.rb:5:in `<module:Hashie>'
hashie-3.5.0/lib/hashie/array.rb:4:in `<top (required)>'
hashie-3.5.0/lib/hashie/mash.rb:2:in `<top (required)>'
omniauth-1.3.2/lib/omniauth/strategy.rb:1:in `<top (required)>'

Looking into trying to debug this.
We use a lot of gems in our project

Any insight would be great, thanks

@kbrock kbrock referenced this issue in omniauth/omniauth Jan 31, 2017

Closed

reference hashie top level #871

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Jan 31, 2017

Contributor

Oh no.

A fix similar to #368 is probably needed, @kbrock would you give it a try? I am not sure how we can guard against this forever, the better fix is probably not to require 'hashie/mash' in downstream gems moving forward.

/cc: @michaelherold

Contributor

dblock commented Jan 31, 2017

Oh no.

A fix similar to #368 is probably needed, @kbrock would you give it a try? I am not sure how we can guard against this forever, the better fix is probably not to require 'hashie/mash' in downstream gems moving forward.

/cc: @michaelherold

@dblock dblock added the bug? label Jan 31, 2017

@kbrock

This comment has been minimized.

Show comment
Hide comment
@kbrock

kbrock Jan 31, 2017

@dblock yup, am testing a fix here, and also made that suggestion over in omniauth.

kbrock commented Jan 31, 2017

@dblock yup, am testing a fix here, and also made that suggestion over in omniauth.

@jrafanie

This comment has been minimized.

Show comment
Hide comment
@jrafanie

jrafanie Jan 31, 2017

Contributor

It makes sense to me especially with the current hashie test suite requiring toplevel hashie in spec_helper, it's impossible for this suite to detect a regression that other projects might have.

Perhaps, hashie should deprecate the current behavior used by other gems and raise in the future if other gems try to load only parts of hashie (without the toplevel).

Contributor

jrafanie commented Jan 31, 2017

It makes sense to me especially with the current hashie test suite requiring toplevel hashie in spec_helper, it's impossible for this suite to detect a regression that other projects might have.

Perhaps, hashie should deprecate the current behavior used by other gems and raise in the future if other gems try to load only parts of hashie (without the toplevel).

@jrafanie jrafanie referenced this issue in ManageIQ/manageiq Jan 31, 2017

Merged

Lock gemfile version of hashie #13709

andrew added a commit to librariesio/libraries.io that referenced this issue Jan 31, 2017

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Jan 31, 2017

Contributor

I'm trying to add an integration spec in #392.

Contributor

dblock commented Jan 31, 2017

I'm trying to add an integration spec in #392.

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

@jrafanie

This comment has been minimized.

Show comment
Hide comment
@jrafanie

jrafanie Jan 31, 2017

Contributor

I'm trying to add an integration spec in #392.

Nice @dblock. That would be great if it fails in the same way.

Contributor

jrafanie commented Jan 31, 2017

I'm trying to add an integration spec in #392.

Nice @dblock. That would be great if it fails in the same way.

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

kbrock added a commit to kbrock/hashie that referenced this issue Jan 31, 2017

Since hashie/mash can be required alone, require its dependencies
Fixes #391

### require ruby_version

ruby_version_check accesses ruby_version.

Since array is one of the first files required, this is sufficient to
resolve this class.

### move logger

The only component that uses logger is mash. Move the logger to
where it is used.

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

@jsmartt jsmartt referenced this issue in HewlettPackard/oneview-chef Jan 31, 2017

Closed

[Travis] hashie gem is causing an error #163

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

dblock added a commit to dblock/hashie that referenced this issue Jan 31, 2017

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Jan 31, 2017

Contributor

I have a fix in #392, with a spec this time that reproduces the problem as is, if anyone cares to give it a try?

Contributor

dblock commented Jan 31, 2017

I have a fix in #392, with a spec this time that reproduces the problem as is, if anyone cares to give it a try?

@michaelherold

This comment has been minimized.

Show comment
Hide comment
@michaelherold

michaelherold Jan 31, 2017

Contributor

@jrafanie That's an interesting suggestion.

Contributor

michaelherold commented Jan 31, 2017

@jrafanie That's an interesting suggestion.

michaelherold added a commit that referenced this issue Jan 31, 2017

@michaelherold

This comment has been minimized.

Show comment
Hide comment
@michaelherold

michaelherold Jan 31, 2017

Contributor

I just released version 3.5.1.

I think we'll yank 3.5.0 (I'll do it at the end of the work day today) unless someone has a reason not to.

I apologize for the breakage, everyone!

Contributor

michaelherold commented Jan 31, 2017

I just released version 3.5.1.

I think we'll yank 3.5.0 (I'll do it at the end of the work day today) unless someone has a reason not to.

I apologize for the breakage, everyone!

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Jan 31, 2017

Contributor

I would keep 3.5.0 cause the mash problem only affects a small portion of gems that require hashie/mash. It will just add pain and suffering to anyone who's working OK and got locked at 3.5.0.

Contributor

dblock commented Jan 31, 2017

I would keep 3.5.0 cause the mash problem only affects a small portion of gems that require hashie/mash. It will just add pain and suffering to anyone who's working OK and got locked at 3.5.0.

@jrafanie

This comment has been minimized.

Show comment
Hide comment
@jrafanie

jrafanie Jan 31, 2017

Contributor

I agree with @dblock, those of us who hit this will be fine to upgrade to 3.5.1.

Contributor

jrafanie commented Jan 31, 2017

I agree with @dblock, those of us who hit this will be fine to upgrade to 3.5.1.

@michaelherold

This comment has been minimized.

Show comment
Hide comment
@michaelherold

michaelherold Jan 31, 2017

Contributor

Good point, thanks!

Contributor

michaelherold commented Jan 31, 2017

Good point, thanks!

@kbrock

This comment has been minimized.

Show comment
Hide comment
@kbrock

kbrock Jan 31, 2017

thanks all

kbrock commented Jan 31, 2017

thanks all

@bodrovis

This comment has been minimized.

Show comment
Hide comment
@bodrovis

bodrovis Jan 31, 2017

This indeed does fix the problem, however now I am getting a warning:

WARN -- : You are setting a key that conflicts with a built-in method OmniAuth::AuthHash::InfoHash#name defined at F:/Ruby225/lib/ruby/gems/2.2.0/gems/omniauth-1.3.2/lib/omniauth/auth_hash.rb:34. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.

This indeed does fix the problem, however now I am getting a warning:

WARN -- : You are setting a key that conflicts with a built-in method OmniAuth::AuthHash::InfoHash#name defined at F:/Ruby225/lib/ruby/gems/2.2.0/gems/omniauth-1.3.2/lib/omniauth/auth_hash.rb:34. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.

@bodrovis bodrovis referenced this issue in zquestz/omniauth-google-oauth2 Jan 31, 2017

Closed

Compatibility with Hashie 3.5.0 #265

@bmclean bmclean referenced this issue in omniauth/omniauth Jan 31, 2017

Closed

Hashie warnings #872

@michaelherold

This comment has been minimized.

Show comment
Hide comment
@michaelherold

michaelherold Jan 31, 2017

Contributor

That's because they have an OmniAuth::AuthHash::InfoHash#name method, which is often set with the writer method Mash#name=. We often have people complain that the Mash behavior isn't what they expect when a key collides with a built-in method, so we added logging to that point.

If you aren't using Hashie anywhere else, you can set the Hashie logger to a nil logger with:

Hashie.logger = Logger.new(nil)

in an initializer.

Contributor

michaelherold commented Jan 31, 2017

That's because they have an OmniAuth::AuthHash::InfoHash#name method, which is often set with the writer method Mash#name=. We often have people complain that the Mash behavior isn't what they expect when a key collides with a built-in method, so we added logging to that point.

If you aren't using Hashie anywhere else, you can set the Hashie logger to a nil logger with:

Hashie.logger = Logger.new(nil)

in an initializer.

@bodrovis

This comment has been minimized.

Show comment
Hide comment
@bodrovis

bodrovis Jan 31, 2017

@michaelherold Yeah, makes sense. Thank you!

@michaelherold Yeah, makes sense. Thank you!

@inchr

This comment has been minimized.

Show comment
Hide comment
@inchr

inchr Feb 1, 2017

I've yet this problem and my Gemfile look like this:
gem 'omniauth', :github => 'omniauth/omniauth'
gem 'omniauth-twitter', :github => 'arunagw/omniauth-twitter'
And in my Gemfile.lock hashie is this:
hashie (3.5.1)

inchr commented Feb 1, 2017

I've yet this problem and my Gemfile look like this:
gem 'omniauth', :github => 'omniauth/omniauth'
gem 'omniauth-twitter', :github => 'arunagw/omniauth-twitter'
And in my Gemfile.lock hashie is this:
hashie (3.5.1)

@dblock

This comment has been minimized.

Show comment
Hide comment
@dblock

dblock Feb 1, 2017

Contributor

@inchr Can you copy-paste the error you're getting with the stack please?

Contributor

dblock commented Feb 1, 2017

@inchr Can you copy-paste the error you're getting with the stack please?

@inchr

This comment has been minimized.

Show comment
Hide comment
@inchr

inchr Feb 1, 2017

weird, now it don't give me the error anymore :)

but give me a warning:
[2017-02-01T17:31:40.874860 #91523] WARN -- : You are setting a key that conflicts with a built-in method OmniAuth::AuthHash::InfoHash#name defined at /Users/inchr/.rvm/gems/ruby-2.3.3/bundler/gems/omniauth-01809cb63237/lib/omniauth/auth_hash.rb:34. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.

inchr commented Feb 1, 2017

weird, now it don't give me the error anymore :)

but give me a warning:
[2017-02-01T17:31:40.874860 #91523] WARN -- : You are setting a key that conflicts with a built-in method OmniAuth::AuthHash::InfoHash#name defined at /Users/inchr/.rvm/gems/ruby-2.3.3/bundler/gems/omniauth-01809cb63237/lib/omniauth/auth_hash.rb:34. This can cause unexpected behavior when accessing the key via as a property. You can still access the key via the #[] method.

@bodrovis

This comment has been minimized.

Show comment
Hide comment
@bodrovis

bodrovis Feb 1, 2017

@inchr see above #391 (comment) Though the suggested fix does not really help :(

bodrovis commented Feb 1, 2017

@inchr see above #391 (comment) Though the suggested fix does not really help :(

@michaelherold

This comment has been minimized.

Show comment
Hide comment
@michaelherold

michaelherold Feb 1, 2017

Contributor

I'm working on a patch for Hashie that will make this behavior toggleable. I'll then make a patch for OmniAuth to take care of that functionality.

Contributor

michaelherold commented Feb 1, 2017

I'm working on a patch for Hashie that will make this behavior toggleable. I'll then make a patch for OmniAuth to take care of that functionality.

@romeuhcf

This comment has been minimized.

Show comment
Hide comment
@romeuhcf

romeuhcf Feb 10, 2017

Hi. Problem persists here and only gets better when downgraded to hashie v3.4.6.

Gemfile with:

rails (5.0.1)
hashie (3.5.2)
omniauth (1.4.1)
omniauth-gplus (2.0.1)

Ruby 2.3.1

Backtrace:

Backtrace for gem load error is:
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:334:in `log_built_in_message'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:139:in `custom_writer'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:207:in `block in deep_update'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:200:in `each_pair'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:200:in `deep_update'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:115:in `initialize'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/omniauth-1.4.1/lib/omniauth/auth_hash.rb:24:in `new'
...
/home/romeu/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/singleton.rb:140:in `instance'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/omniauth-1.4.1/lib/omniauth.rb:119:in `config'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/omniauth-oauth2-1.4.0/lib/omniauth/strategies/oauth2.rb:127:in `<top (required)>'

...
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/bundler-1.14.3/lib/bundler.rb:107:in `require'
/home/romeu/Projetos/Pessoal/genesis/config/application.rb:7:in `<top (required)>'

Full backtrace here: https://gist.github.com/romeuhcf/edf0b50cdbc9975b19aa7eb2e4148378

Hi. Problem persists here and only gets better when downgraded to hashie v3.4.6.

Gemfile with:

rails (5.0.1)
hashie (3.5.2)
omniauth (1.4.1)
omniauth-gplus (2.0.1)

Ruby 2.3.1

Backtrace:

Backtrace for gem load error is:
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:334:in `log_built_in_message'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:139:in `custom_writer'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:207:in `block in deep_update'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:200:in `each_pair'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:200:in `deep_update'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/hashie-3.5.2/lib/hashie/mash.rb:115:in `initialize'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/omniauth-1.4.1/lib/omniauth/auth_hash.rb:24:in `new'
...
/home/romeu/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/singleton.rb:140:in `instance'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/omniauth-1.4.1/lib/omniauth.rb:119:in `config'
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/omniauth-oauth2-1.4.0/lib/omniauth/strategies/oauth2.rb:127:in `<top (required)>'

...
/home/romeu/.rvm/gems/ruby-2.3.1@genesis-devise/gems/bundler-1.14.3/lib/bundler.rb:107:in `require'
/home/romeu/Projetos/Pessoal/genesis/config/application.rb:7:in `<top (required)>'

Full backtrace here: https://gist.github.com/romeuhcf/edf0b50cdbc9975b19aa7eb2e4148378

@bodrovis

This comment has been minimized.

Show comment
Hide comment
@bodrovis

bodrovis Feb 10, 2017

Same here, this happens with Hashie 3.5.2, but not with 3.5.1

Same here, this happens with Hashie 3.5.2, but not with 3.5.1

@bodrovis

This comment has been minimized.

Show comment
Hide comment
@bodrovis

bodrovis Feb 10, 2017

Discussed in #401

Discussed in #401

@rizidoro rizidoro referenced this issue in noverde/lecca_client Mar 8, 2017

Merged

fix annoying hashie warning #8

petems added a commit to petems/tugboat that referenced this issue Mar 18, 2017

Fixes hashie warning for methods
```
W, [2017-03-18T22:33:20.253963 #55813]  WARN -- : You are setting a key that conflicts with a built-in method Hashie::Mash#size 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.
```
* Properly fix later: intridea/hashie#391

@petems petems referenced this issue in petems/tugboat Mar 18, 2017

Merged

Fixes hashie warning for methods #264

visoft added a commit to visoft/goodreads that referenced this issue May 16, 2017

lincredibleJC added a commit to nusskylab/nusskylab that referenced this issue Jun 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment