NOTE Undusting this post as better response to a conversation in Tweeter, with tenderlove and nickseiger
Nick commented out here that Ryan Tomayko post is correct.
Well, kind of, sorta… not entirely correct.
Mandatory warning
Take the following statements with a grain of objectivity without pondering how much bits and bytes a packaging solution like RubyGems adds to your scenario.
Now, let me present this with a story (I love stories)
Creating my application or library
I had an excellent idea for a new library we needed here at the office. This library will provide a client-side OOP access to a remote webservice we use daily.
After investigation of my remote webservice API and structure and exploration of existing HTTP/REST like interfaces, I decided that would be best to invest my time in leverage the low-level HTTP complexity to an existing library published by another developer.
Filling the gaps and start working
Started creating my library (called Foo) and based the internals calls on what was published for Bar at that time (let’s say was version 1)
So far, everything is great. Everything works great on my computer.
Time to share
It has been 2 weeks since I created this library and we internally wanted to use in another project.
This time, my colleague check out my library repository and try to use the library.
He realizes that Bar is required and is not present in his environment, which leads him to start a gem installation process.
He succeed installing Bar version 2, as is the latest available version by the developer of it, but my library no longer works with it, since there are several API changes.
Spotting that issue can be simple, but now think the following: I’ve used Rip instead of Rubygems, and Rip uses repositories directly, not packaged versions.
So now, Foo is not only version specific, but commit specific since the developer of Bar could have changed API between commits to finalize or stabilize it.
Even worse could be that I used setup.rb that was part of Bar and installed inside my Ruby installation, which then will make complicated to figure out which version I used to implement Foo
But what if…
- Usage of Git submodules for my dependencies… if I’m using Git at all.
- Gemify my library, which then will lead to negative comments from others about me imposing a packaging system on them.
- Do not release or share my library at all. Problem solved.
Add to that, that even if I released my library as a gem or not, there is no way to determine the usage of my Foo from Joe’s Foo variation. Something I raised about GitHub gem forks and commented out here
So, try all the approaches, get your own conclusions, but don’t say that the way I implement something is flawed. That is plain subjective.
It’s not entirely subjective: It’s a trade off, with measurable overhead.
On the one hand, there’s the known overhead of using RubyGems, which may or may not lock another developer into a specific configuration.
On the other hand, there’s the unknown overhead of dealing with versioning issues. You can figure that out, but it is difficult to track down, and costs time. It’s a lot of yak shaving, in other words.
You trade the ease of use of RubyGems for overhead, and you trade the overhead of keeping track of version conflicts for a smaller memory and CPU footprint.
Me, I’d rather incur RubyGems’ overhead than the hassle of maintaining my own repository of foreign sources (and quite likely different coding styles from my own, which adds another layer of complexity entirely).