-
-
Notifications
You must be signed in to change notification settings - Fork 251
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Option name must be a kind of String!" when installing gems #107
Comments
We have the same problem. |
@leifmadsen what version of Chef were you using. I just ran into this on 12.1.1, but didn't see it with 12.0.3. I'm curious what Opscode changed that introduced this behavior. |
I am also experiencing this issue with 12.1.1, on ubuntu 14.04, after applying two of the fixes in open PRs here to my fork's master branch. |
I'm fairly certain this issue came about with the 12.1 multi package support changes made in Chef. This cookbook extends the rubygems provider, which was changed extensively with that new feature. I don't run into the issue with Chef 12.03, but I do with 12.1.1 |
@tas50 yea I have a plugin on Vagrant that automatically upgrades Chef to the latest client, so it will be a 12.1.x something client. |
really need the stacktrace suspect its not the rubygems provider changes but the changes to force the name into a string, but without the full stacktrace all we can do is guess. |
The name attribute in Chef::Resource also accepts anything that can be |
@lamont-granquist I've got an example that triggers it here. Here's the end result of a failed chef-client run with it: Here's the associated stacktrace: I think the chef-client run message shows the offending resource completely, but in case it's helpful here is the definition code that calls the resources (called is this example from another cookbook's recipe named |
I poked around a little. Does https://github.com/fnichol/chef-rbenv/blob/master/libraries/chef_provider_package_rbenvrubygems.rb#L86 need to be |
@troyready great, thanks. Submitting a PR to update the cookbook for that is probably the easiest fix. I tried something like this, and it works fine:
Perhaps it's limited to changes in LWRP though. It looks like it was this change: chef/chef@d6d4fd8#diff-135510b4e9e7ac268144bf6a7479a94dL94 Maybe we could do something like |
I still don't understand how it was that change though? The prior behavior was actually much stricter there where passing a Chef::Resource should raise because its not a String so what was happening in 12.0.3 to make it work? |
And checking for Chef::Resource passed to name of some other resource is pretty immense code smell... That's a huge hack introduced into core chef to work around this one bug. |
And when that function is hit with a Chef::Resource with the new code we call #to_s on the Resource which would be something of the format |
FWIW, this cookbook has other issues with Chef v12.0 (e.g. #98/#108), so if this cookbook's current implementation is the only emacs-temperature-rise-user then I think it would be reasonable to just force this cookbook to change. Just my opinion as one of the people maintaining a fork of it for Chef v12 support. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
When trying to install a gem, I get this error in Vagrant:
The
Vagrantfile
contains this section (commented out section ofgems
causes above issue; runs clean if commented out):The text was updated successfully, but these errors were encountered: