if you don’t want to hoe… echoe

January 10, 2007 By in Uncategorized 11 Comments

Hoe, a gem used to build gems, injects itself as a dependency into every gem it creates. To many people, this is unnecessary, since hardly anybody wants to perform meta-operations on a gem itself. Mainly they just want to use the included library.

update

The latest documentation for Echoe is here.

update 2

I don’t recommend bothering with the conditional require anymore. People can figure out a LoadError easily enough, and it really clutters up the Rakefile.

the fork of destiny

But we don’t want unused libraries on the production server. What to do? Forget Hoe, and write the Rakefile by hand? I’ve certainly seen people do that. But remember, Hoe is open source. So let’s fork it:

sudo gem install echoe

Echoe is part of the Snax Fauna, little beasts running all over the place.

what’s changed?

Echoe 1.0.0 is based on Hoe 1.1.6. However, it does not inject itself as a dependency. If you want to still publish meta tasks in a Rakefile, you could do as follows:

require 'rubygems'
require 'rake'
begin
  require 'echoe'

  # all your regular Echoe/Hoe config

rescue LoadError => boom
  puts "You are missing a dependency required for meta-operations on this gem."
  puts "#{boom.to_s.capitalize}."

  desc 'No effect.'
  task :default; end

  # if you still want tests when Echoe is not present
  desc 'Run the test suite.'
  task :test do
     system "ruby -Ibin:lib:test some_tests_test.rb" # or whatever
  end
end

Then, people can still run the tests, and in the unlikely event that they want to mess with the gem itself, they can install Echoe. But nothing is forced on you. No opinions. No vinegar. No badgers.

Maybe badgers.

11 responses

  2. Isn’t a fork a huge overreaction?

    If you don’t want your gem dependant on Hoe, all you have to do is set p.extra_deps = [] in the block you pass to the hoe constructor.

  3. Not as of Hoe 1.1.7, you can’t. The fact that the Hoe developers wouldn’t tell anyone about this possibility in earlier revisions suggested it was an oversight.

  4. Ok, so slap the following code (only one of many ways it could be done) above the Hoe.new in your rakefile

    class Hoe
  def extra_deps
    @extra_deps.reject do |x|
      Array(x).first == 'hoe'
    end
  end
end

    Code that did a similar thing could be packaged into an Echoe gem, requiring 'echoe' would require 'hoe' and then run that code. A fork still seems wildly excessive to me.

  5. I’m not casting aspersions on the Hoe developers by forking the gem. I’d just rather maintain my own version, then try to continually play catch-up with Hoe to implement a feature the devs are publicly opposed to. If I (and the 3 other people who will use this) need newer Hoe features, I can import the differences at that point.

    A gem that monkey-patches a specific version of the original Hoe seems (relatively) less maintainable to me.

  6. I understand what you’re saying, I guess we just disagree. Your Echoe gem could require 1.1.7 of Hoe, and you could do version bumps to require newer hoe versions at your pace.

    If the goal is really for you and several people you know to use Hoe without adding the dependency, adding the monkeypatch right in your makefile seems the course of least resistance. Again, that’s just my opinion.

  7. Yeah, I understand. As long as the patch/change/hack to Hoe is centrally located, it’s kind of a toss-up. Both ways are good.

  8. Right. I guess my instinct is never to fork unless you have no other options.

    Obviously, in this case, all a “fork” is is copying the content of 1 file, so what’s the big deal? I personally wouldn’t, but it’s reasonable, if you’re intent on making a gem solution.

  10. AJ, is quite common way of reply to suggestions, like #7389.

    Not to start a flame war, but hope not lot of member of seatle.rb group do the same with other suggestions.

  11. The newgem gem is now updated with the idea from Mike H for ignoring hoe during deployment/installation/general usage.