Metric_fu just released version 1.1.0 of their gem which I'm pleased to say includes a patch submitted by me. This is exciting as its the first time I've had my code included by someone I don't know in one of the open source projects I admire.

I was not originally going to make the patch as I thought I'd just hack around to fix the problem locally just enough to get it working but my friend Matt encouraged me to fix the root cause which turned out to be not too hard and got me into the metric_fu source. I always learn something when I read source from others I admire.

The process of submitting the patch was pretty easy and I plan to make it a habit when I run into issues with other gems. I,

1. Experienced a problem and decided not to live with it
   
2. Created a fork of metric_fu on github
3. Cloned locally and iteratively made my changes until I had my fix complete
4. Rebased my changes into a single commit (I wrote an article on this a few weeks ago)
5. Pushed my patch back to github on a branch
6. Submitted my patch back to Jake's repository as an issue
   

Solving the problem of gem dependencies with github names

I am using relevance-rcov instead of the rubyforge version of rcov as it has been maintained more recently and specifically fixed a segmentation fault problem I previously faced. The problem is that I couldn't install metric_fu as it put a gem dependency on 'rcov' in its gemspec. What seems broken is that there's no way to put a dependency on 'rcov' but have rubygems realize that 'relevance-rcov' is a fork of rcov so should satisfy the dependency.

I've seen a lot of talk recently about rubygems (including Why Using require ‘rubygems’ Is Wrong, RubyGems: Problems and (proposed) Solutions and Rip: A Next Generation Ruby Packaging System - Watch Out RubyGems!) but so far I haven't found a solution to the forking and naming problem emerge.

For Metric_fu I decided to change the install-time dependency to a runtime one. This solves my basic problem of not finding relevance-rcov but also allows for more flexibile use of metric_fu. If someone does not want to generate reek or rcov metrics why should they be forced to install those gems in order to use metric_fu? By defering the dependency until runtime we will never hit the dependency for those metrics we are not using.

You can look through the commit to see exactly how I did this.

1. Deleted the install time dependencies from metric_fu.gemspec
2. Added the runtime dependencies when a specific type of metric is instantiated by
• Inserting a verify_dependencies! strategy step to the initialization in lib/base/generator.rb
• Implementing verify_dependencies! in each of the subclasses for different metrics in lib/generators/*
  
3. Did it with TDD writing tests around everything before implementing my changes
   

Should gems use install time dependencies? Should a gem author decide which fork of a gem is required? What do you think?