However, it depends on ruby-debug which is incompatible with 1.9.x. I did a quick fork of rack-debug to conditionally depend on ruby-debug19, but when I submitted the pull request, ddollar rightly pointed out that the conditional logic in creating the gemspec wouldn’t work. It would only make a version of the gem for the ruby version on the machine that cut the gem, and there’s no way to have conditionals in gemspecs b/c they are YAML. He did however point me to a 1.9.x version he cut, rack-debug19.

The install instructions aren’t up-to-date for Rails 3, so here’s my version.

# Gemfile
group :development do
  gem "ruby-debug19"
  gem "rack-debug19", :require => 'rack-debug'
end

# Rakefile
require 'rack-debug/tasks'

# development.rb
YourAppName::Application.configure do
  config.middleware.use 'Rack::Debug'
...
end

We specify a ‘:require’ in the gemfile b/c the gem name has changed, but the libs inside have the original name and bundler needs to require them as such.

Fire off ‘bundle install’, and things should go nicely, with 1.9.x-appropriate version of our debug libs and all their dependencies.

Autotest is also incredibly useful, but it doesn’t find specs by default. It very much likes there to be a ‘test’ directory, with files named like ‘test_foo.rb’.

If you use rspec, it registers its own mappings for autotest and you never have to worry.

Autotest’s source recommends implementing an ‘autotest/discover.rb’ in your project, which it finds and runs automagically for you.

Through some sniffing around the rspec codebase, I came up with this ‘discover.rb’ for a gem I’m working on. It finds ‘spec/lib/foo_spec.rb’ and looks for an implementation class of ‘lib/foo.rb’. It’s really just a super-simplification of rspec’s discovery strategy.

Autotest.add_hook :initialize do |at|
  at.clear_mappings
  at.add_mapping(%r%^lib/(.*)\.rb$%) { |_, m|
    ["spec/lib/#{m[1]}_spec.rb"]
  }
end

class Autotest::MiniSpec < Autotest
end

The other part required to make autotest happy is a nice ‘.autotest’ file in the project.

require 'autotest/restart'

Autotest.add_hook :initialize do |at|
  at.testlib = 'minitest/spec'

  at.add_exception 'coverage.info'
  at.add_exception 'coverage'
end

There’s probably a nice way to combine these, given that they both are patching the initialize hook.

And for good measure, here’s the ‘spec/lib/spec_helper.rb’ I’m including in all the specs:

$LOAD_PATH.unshift(File.dirname(__FILE__))
$LOAD_PATH.unshift(File.join(File.dirname(__FILE__), '..', 'lib'))

require 'minitest/autorun'

# Try to make the output nice and fancy with 'turn'
begin
  require 'turn'
rescue LoadError
  puts "Could not find gem 'turn', continuing without prettiness."
end

He could run ‘rake db:create’ and ‘rake db:drop’ with success, but ‘rake db:migrate’ would fail silently. This is a problem we didn’t find easily in Google, so I’m writing this for posterity.

First step, throw ‘–trace’ on the end.

bash$ rake db:migrate --trace
<snip>
** Invoke environment (first_time)
** Execute environment
bash$

That’s odd. So I took a look in the rails gem at the rake files. As suspected, ‘db:drop’ and ‘db:create’ have different prereqs than ‘db:migrate’, which includes “=> :environment” (load the whole Rails environment) in its task definition.

A quick test rakefile added to his project validated the conclusion:

task :noenvtest do
  puts "*** ohai no env"
end

task :envtest => :environment do
  puts "*** ohai env"
end

As expected, ‘rake noenvtest’ gave output, and ‘rake envtest’ failed silently again.

So, we took a look at his gems. While he had rails 2.3.8 and friends, his rubygems was at 1.3.4 and his gem sources were out of date. We deleted the old sources (gem source -r http://gems.rubyforge.org) and added the right one. Updated the rest of his gems, and db:migrate runs again!