This post originated from an RSS feed registered with Java Buzz
by Bill de hÓra.
Original Post: Installing gRPC for Ruby on Mac OSX Yosemite
Feed Title: Bill de hÓra
Feed URL: http://www.dehora.net/journal/atom.xml
Feed Description: FD85 1117 1888 1681 7689 B5DF E696 885C 20D8 21F8
I've been looking at HTTP2 recently along with the gRPC framework. One of the things I wanted to try out was cross language interchange. Herein some notes on getting things working for Java and Ruby on Mac OSX Yosemite, that might be of help to someone.
The gRPC project has not hit a final release yet but is being worked on heavily. The range of language support is good - the Java project, grpc-java is standalone, but Python, Ruby, Node, PHP, C#, Objective-C and C++ depend on shared code and live with the core and compiler codebase. To cap it off gRPC depends on protocol buffers 3, which itself is moving towards a final release.
I solve problems
As mentioned, [grpc-java](https://github.com/grpc/grpc-java) is the main project for JVM, and it looks to be in good shape for a pre-1.0 project. The commits have the feel and urgency of code resulting from day to day use. There is Gradle build support in the form of the protobuf-gradle-plugin, which integrates with the standard build task to generate your code from the protobuf message file. It didn't take long to figure out the stanzas for sourceSets and protobuf tasks. This is a nice change from my experience working with protocol buffers in the past through pre-compile scripts and I expect is especially helpful if you're looking at gRPC or HTTP/2 interchange for Android. There's a simple standalone project I put together here that uses the Hello Word example pretty much as is from the grpc-java project.
I'm also interested in the state of gRPC for Ruby and Python. I haven't gotten to Python yet, but did manage to get basic exchanges going between Ruby and Java. That said, getting gRPC setup on Mac OSX with Ruby was a bit of a bear. Mostly the problems were mismatches between versions of gem specs, gRPC core and protocol buffers. Pretty much the usual stuff you see in the run-up to a major release - everything in gRPC is pre-release and evolving quickly right now, and while thing seem to work well, getting up and running was time-consuming.
Didn't go into a Burger King
The first thing, after digging around the code in the grpc project and reading make errors was to remove the existing protoc I had installed along with its header files as the older copy of protoc3 was gettting in the way. The includes were in '/usr/local/include/' (the Mac I use has a mismash of boxen and brew, so your details may vary).
The instructions to install gRPC via homebrew-grpc are very simple - a one line curl command. Unfortantely the targeted version, 0.10.0 wouldn't apply - it seems there were native signature bugs for Ruby in 0.10.0 (since fixed). There is a 0.10.2 tarball available, but that also failed as it requires a more recent protoc 3 version. The answer in the end was the patch the formula files up to more recent versions. There's a fork of the project here that uses versions gRPC 0.11.0 and google-protobuf 3.0.0-beta-1 as those two worked for me. To install them copy the two formula .rb files from Formula into "/usr/local/Library/Formula/" and then run -
brew install google-protobuf --without-python
brew install grpc
to produce (after some hours of digging), a working installation with "brew list --versions" showing
google-protobuf 3.0.0-beta-1
grpc 0.11.0
The python support, which is on by default, didn't work for me due to signature mismatches, probably because the python resources in the formula are stale. You might be able to get protoc installed with the default python, but my patience digging into native code had run out at this point :) I'l go into that Burger King another time.
Version Fox Force Five
The last step for Ruby is to install the grpc gem. There was no published version that worked against the versions above and the answer was to patch the "grpc.gemspec" file in the grpc projects' "./src/ruby" area by by removing the "google-protobuf" dependency line entirely and making sure "libgrpc" is set to "~> 0.11.0". Then run
gem build grpc.gemspec
gem install ./grpc-0.11.0.gem
The updated gem will appear in "gem --list". After all that, in your Gemfile you'll be able to declare -
gem 'google-protobuf', '~> 3.0.0.alpha.3.1.pre'
gem 'grpc', '0.11.0'
The "3.0.0.alpha.3.1.pre" above is a cheat - it should really be 3.0.0-beta-1 to match up with the underlying protoc version installed by Brew, but as far as it goes it's been working well enough to test things out, which is all I need for the moment.
I haven't gotten round to publishing a patched gRPC gem or patching "google-protobuf" to get to "3.0.0-beta-1 " , but I'm hoping I won't have to as gRPC 0.11.0 just moved into beta (today! I should have held out!) which means a round of uplifts are coming that will avoid the messing around above.
Say interop one more time
The interesting observation here is how gRPC dependencies ripple down into protocol buffers and up to language libraries. It's not what you'd want to deal with generally, but I'm not overly concerned. I suspect things will harden once gRPC and Protocol Buffers hit their upcoming major releases. Protocol buffers 2 has, at least historically, has done a good job on stability, as in good enough to be used for storage - I recall a incident with the java library singatures a good few years back, but that's about it. Also other Google OSS projects tends to take their versioning seriously - Guice and Guava come to mind. Finally, HTTP/2 is baked, the next phase is really about adoption of its core elements and while it's understandable to be concerned about binary wire formats, it's going to interop well and have good tools.
In any case, Ruby/Java interop looks to work so far. This is what I've come to expect from protocol buffers over the years, but protoc 3 has some new features such as Maps that I wanted to see working and see how the they get serialized and marshalled. Also while HTTP/2 uptake is strong - there's very little doubt in my mind it will supersede HTTP over the years, you always want to see stuff working over the wire first hand.
Previous Topic
