Sep 23
2010

Calling Gem-Based Rake Tasks from Step Definitions

Posted by Elliott Golden
header line 
I am working on a Rails 3 CMS Gem that relies on a few Rake tasks. The *.rake files are located within my_gem/lib/tasks. When the Gem is built and installed, the tasks are available as expected from the requiring app. However, calling them from my Cucumber steps results in the Don't know how to build task * message.

Due to my Gem's requirements, I'm building it within vendor of a full Rails app. Running rake -T from this dev environment shows all tasks available except the ones I added to my Gem's lib/tasks directory.

At first, I tried adding a Rails::Railtie#rake_tasks call from Cucumber's env.rb. That is how the tasks are added from the Gem's lib init file for production. However, I could not get the same thing to work in my test env. 

A quick look at Rake's options provided the answer.

rake -h
...
-R, --rakelibdir RAKELIBDIR      Auto-import any .rake files in RAKELIBDIR. (default is 'rakelib')
...

Knowing how to add dirs to Rake's lookup process solved the problem. Running
rake -T -R lib/tasks now showed that my Gem's tasks were now accessible to Rake.

The final piece of the puzzle was to make a simple step definition that I could pass tasks to for execution.

When /^I call the task "([^"]*)"$/ do |task|
  `#{task} -R lib/tasks`
end
Comments
Sep 21
2010

Taking a Rails 3 Gem From Development to Production

Posted by Elliott Golden
header line 
I have been working on a Rails 3 CMS Gem called Twist over the last few weeks. Due to it's inherent dependency on the full Rails stack, I am working on it in the context of complete Rails app. The Gem's code is sitting inside of the vendor dir and is reliant on a few hardcoded "tricks" within the app to make development possible. Setting up this environment for Cucumber and RSpec 2 is another post unto it self, so I won't get into that now. This is just about getting a Gem from a heavily coupled dev space into a working production state, less deployment to rubygems.org.

I finished up Twist's authentication and authorization system the other day. I figured it was a good time to go ahead and locally build and install them Gem to see what would break when I required it in a fresh app. Several things kept the Gem from firing up, here's how I fixed them and a few resources that helped me do so.

Compared to Rails 2, Rails 3 pulls in plugin/Gem code very early in the boot process. This meant that I had to wrap most of my init code in one of the new Active Support spin up hooks so that certain required modules and classes would be available when called.


# lib/twist_cms.rb
ActiveSupport.on_load(:after_initialize) do
...
end


In the dev environment I was calling Twist's dependencies directly through the host app's Gemfile as a convenience. Of course this broke things when Twist went to a production state. The easy fix here was to just call require for each needed Gem in lib/twist_cms.rb.

Twist also uses a couple custom generators and Rake tasks to get things done. This Rails Dispatch post goes into detail on setting these things up (amongst others) from a Gem's perspective.
how-rails-3-enables-more-choices-part-1

Here's two other great posts from Yehuda and José Valim that got me up to speed on Rails 3 and plugins/Gems.
rails-and-merb-merge-plugin-api-part-3-of-6

building-or-updating-a-rails-3-plugin
Comments
All 2 Posts


top All content in this site is copyright protected by either Simple Circle llc or its respective clients.   © 1999-2010
Validate XHTML