Organizing common (library) code

Hello,

I’m pretty new to Ruby. I have put together a library of Ruby code for
interfacing with the web APIs of a crash reporting service
(HockeyApp), and a separate library of code for interfacing with the web
APIs of a usage & analytics service (Mixpanel).

Next, I’ve written a utility for our in-house metrics team that knits
together results from both of these service libraries, and packaged it
up with a command line interface as a gem, so that they can “easily”
install it (once they go through the enormous hassle of upgrading the
stock version of Ruby that ships on their machines).

Now I’m writing a second utility for a different department, which will
also utilize the two shared service libraries. I would also like to
package it up as a gem for easy deployment. I’m looking for some advice
as to the best practices for how to organize the code. Here is what I
have now.

rubyStuff/
lib/
hockeyapp_services.rb <-- common code to both gems
mixpanel_services.rb <-- common code to both gems
gemA
bin/ <-- the command-line interface part is here
gemA.gemspec
lib/
pkg/
test/
gemB
bin/
gemB.gemspec
lib/
pkg/
test/

… and in my gems, I reference the common code as follows.
rubyStuff/gemA/lib/gemA/runner.rb:
require ‘…/…/…/lib/hockeyapp_services.rb’
require ‘…/…/…/lib/mixpanel_services.rb’

Is there a cleaner way of sharing common library code across gems (and
referencing it from within the gems), or is this pretty good as it
stands? I’m not looking for perfection, just something that won’t slow
other Ruby developers down should they inherit the codeline.

Thanks for your help!

To me the common code seems to be a candidate for a third gem. Then it’s
transparent to require its parts like:

require ‘common/hockeyapp_services’
require ‘common/mixpanel_services’

Vlad M_ wrote in post #1142519:

To me the common code seems to be a candidate for a third gem.

Thanks for your input! Indeed, I ended up putting the common code into
a stand-alone gem. I also discovered thor, which allowed me to put a
very easy command-line interface on it, so that it can be used both as a
library (to my gemA and gemB) as well as a utility for command-line
users.