FYI: Update recursive-open-struct once it supports ruby 2.3.0

[jrafanie]

FYI. @abonas we'll need to upgrade our dependency on this gem once it supports 2.3.0:
aetherknight/recursive-open-struct#39

Note, 2.3.0 is due around December 25th.

The kubeclient test suite fails against ruby 2.3.0preview2 with error like:

  2) Error:
TestComponentStatus#test_get_from_json_v3:
NoMethodError: undefined method `name' for #<Hash:0x007fe1fb7cb688>
    /Users/joerafaniello/Code/kubeclient/test/test_component_status.rb:14:in `test_get_from_json_v3'


  3) Error:
TestPersistentVolume#test_get_from_json_v1:
NoMethodError: undefined method `name' for #<Hash:0x007fe1fc682208>
    /Users/joerafaniello/Code/kubeclient/test/test_persistent_volume.rb:14:in `test_get_from_json_v1'

Everything passes if I hack the Gemfile/gemspec and bundle to use the proposed upstream fix

diff --git a/Gemfile b/Gemfile
index 2818a92..24cc79b 100644
--- a/Gemfile
+++ b/Gemfile
@@ -2,3 +2,5 @@ source 'https://rubygems.org'

 # Specify your gem's dependencies in kubeclient.gemspec
 gemspec
+
+gem 'recursive-open-struct', :github => "Kris-LIBIS/recursive-open-struct", :branch => "master"
diff --git a/kubeclient.gemspec b/kubeclient.gemspec
index ed828f8..ba9205d 100644
--- a/kubeclient.gemspec
+++ b/kubeclient.gemspec
@@ -28,5 +28,5 @@ Gem::Specification.new do |spec|
   spec.add_dependency 'rest-client'
   spec.add_dependency 'activesupport'
   spec.add_dependency 'json'
-  spec.add_dependency 'recursive-open-struct', '= 0.6.1'
+  spec.add_dependency 'recursive-open-struct'
 end

[abonas]

@jrafanie - thanks!
I see that this aetherknight/recursive-open-struct#39 was merged, and a new 1.0 ROS gem was released. It seems to me that bumping kubeclient to work with ROS 1.0 even before Ruby 2.3 is released should be sufficient to address this issue. Is that correct?
(of course, later on, 2.3 should be added to travis.yml for testing matrix)
cc @simon3z

[jrafanie]

Yes @abonas, that would be fine. The ROS should be completely backward compatible with existing use cases. I"m going to run the MIQ test suite against kubeclient with the latest ROS to verify it.

[simon3z]

@jrafanie @abonas about:

gem 'recursive-open-struct', :github => "Kris-LIBIS/recursive-open-struct", :branch => "master"

is that going to track master? It doesn't seem a good idea to track the unstable branch, isn't there any stable branch to follow instead?

[jrafanie]

Good question @simon3z. Yes, that tracks that person's master branch.

That was a local hack to test it.

What I'm suggesting is something like this:

diff --git a/kubeclient.gemspec b/kubeclient.gemspec
index ed828f8..efd580c 100644
--- a/kubeclient.gemspec
+++ b/kubeclient.gemspec
@@ -28,5 +28,5 @@ Gem::Specification.new do |spec|
   spec.add_dependency 'rest-client'
   spec.add_dependency 'activesupport'
   spec.add_dependency 'json'
-  spec.add_dependency 'recursive-open-struct', '= 0.6.1'
+  spec.add_dependency 'recursive-open-struct', '= 1.0.0'
 end

Personally, I'd go with ~> 1.0.0 so it accepts patch level updates to the gem.

[simon3z]

Personally, I'd go with ~> 1.0.0 so it accepts patch level updates to the gem.

@jrafanie @abonas either = 1.0.0 or ~> 1.0.0 (in case they're really strict with the stable branch and they don't break often/ever) is fine by me.

[abonas]

@jrafanie @abonas either = 1.0.0 or ~> 1.0.0 (in case they're really strict with the stable branch and they don't break often/ever) is fine by me.

I would go with = and not ~> because they did break couple of times in the past with regressions that created some issues for us.

[jrafanie]

@abonas @simon3z FYI, if you bump the kubeclient release to 0.10.0, we'll need a openshift_client gem that allows it. It's currently requiring ~> 0.8.0 so it only picks up 0.8.0, 0.8.1, etc. Not 0.9.0, 0.10.0. And we'll need those gem versions updated in the manageiq gemfile. We have 10 days until 2.3.0 is released so it's not a big rush yet.

[jrafanie]

would go with = and not ~> because they did break couple of times in the past with regressions that created some issues for us.

That's fine @abonas. I try to use ~> until a gem behaves badly and then I get really pessimistic and use = too.