Keep it simple : split the gem

As said in previous posts I do like to put modules of code in boxes I can split away from the main codebase.

It serves many purposes including the ability to open source the library to help others.

You usually start small with a pair of modules. At some point you do wrap up more complex things in the same manner. And some times you face something a bit more complex : you want to abstract a layer of different service providers from your main code base.

There are many similar services out there, but it’s quite rare that those are exposing a similar API publicly. And it makes things complex for us. Fog for example is a great example of abstraction above many different platform providers.

As I was writing one such gem I faced a problem : how to only load the code I need for provider X and not load the code used for provider Y ?

In many cases when you ask yourself such question you have to step aside and check if you aren’t just missing a very obvious point.

In this case the obvious part was : split the gem into a core gem and provider specific sub gems. The application will require the provider specific sub gem that will in turn require the core gem. The specs are way cleaner for each gem, the code is also far more simpler. And bonus on top : the whole family is easier to extend.

No need for complex require tests, everything is pretty simple and everybody is smiling.