Duplo

I was having some trouble running rspec within Emacs. One of the gems in my Gemfile was pointing to a git repo, and as a result, bundle was shelling out through Emacs to check my revision using this method:

def revision_from_git
  if File.exists?(scope('.git/HEAD'))
   Dir.chdir scope(".") do
     `git rev-parse HEAD`
    end
  end
end

Since my git lives in a non-standard location, it was failing:

/Users/xxxxxxxx/.rvm/gems/ruby-1.9.2-p290@global/bundler/gems/compass-91a748a91636/lib/compass/version.rb:48:in ``': No such file or directory - git rev-parse HEAD (Errno::ENOENT)

Searching for a solution, I found a page in the EmacsWiki that dealt with this issue, but I didn’t care for any of the solutions there. What I went with was to open ~/.MacOSX/environment.plist with the Property List Editor, and add the path to my git executable to the PATH variable therein. I then had to reboot. The reboot seems to be the only way to get launchd to re-read this file. I launch Emacs via Spotlight, and so it is started by launchd behind the scenes. I tried using launchctl setenv first, as mentioned in the EmacsWiki, but that didn’t seem to work, I’m not sure why.

With the PATH variable set, rspec-mode, and rvm.el loaded, I was able to successfully run my specs from within Emacs.

I was having all sorts of problems upgrading Mildred to Rails 2.1.  A lot of the errors I was seeing were like the following:

ArgumentError in 'TracksController downloading a track by admin should not be a redirection'
wrong number of arguments (0 for 1)
/Users/ewollesen/src/mildred/app/models/track.rb:52:in `title'
/Users/ewollesen/src/mildred/app/models/track.rb:52:in `filename'
/Users/ewollesen/src/mildred/app/controllers/tracks_controller.rb:49:in `download'
./spec/controllers/tracks_controller_spec.rb:82:

It took me a good while to figure out what was going on. The error was strange because as far as I knew, title was a database attribute in the Album model, which was a descendant of ActiveRecord. There shouldn’t have been any arguments required. Indeed, firing up my debugger and running track.album.read_attribute(:title) returned the expected result of “Test Album 1″. I was very puzzled.

I realized that my title method was being overridden, but by what? I started feeding the title method random arguments in the hopes of learning something new. It wasn’t long before I got lucky:

(rdb:1) e track.album.title("x")
NoMethodError Exception: undefined method `content_tag' for #<Album:0x3d5bbfc>

That tipped me off as to what was overriding my title method. The content_for is part of a pattern I use to set a view’s title in the layout via a method called title in my ApplicationHelper. This made me think of how in Rspec 1.1.4, a Helper module is no longer included by default. I popped over to my application_helper_spec.rb and found something similar to this:

require File.dirname(__FILE__) + '/../spec_helper'

include ApplicationHelper

describe "ApplicationHelper" do

This needed to be changed to:

require File.dirname(__FILE__) + '/../spec_helper'

describe "ApplicationHelper" do

  include ApplicationHelper

Then all was well. Whew. Just to be sure I didn’t run into this sort of thing again, I went ahead and made sure that all of my other Helper specs followed this paradigm.

This is the second time I’ve run into an issue where RSpec had overridden some seemingly random method in some seemingly random object. I guess there’s a lot of magic in there that I don’t have my head wrapped around yet. I just wish it were easier to spot!