[Nitro] General inquiry about Reap

James Britt james_b at neurogami.com
Tue Apr 25 00:01:00 EDT 2006

TRANS wrote:
> Hi all,
> I was reading a little about Capistrano (SwitchTower) this evening
> after working most of the day on Reap. What struck me was that
> Capistrano looks just to be an extenion on Rake. Which got me
> wondering in general. So I'd like to ask: What do you think of Reap
> and how it works? For those who haven't used it much here's a quick
> overview...

I've not yet used Reap.  I've grown accustom to Rake. But I'm curious 
about the social/network effects of tool adoption.

Before there was SwitchTower, I has started assembling a set of scripts 
to package and deploy my code.  When I began these scripts they were for 
me alone, so little quirks and system dependencies were acceptable. 
They worked for me, so I was happy.

Working with a team, though, I decided that explaining or hacking around 
these things was a Bad Idea.  I took a look at SwitchTower (which was 
then being renamed to Capistrano), but it was quirky, and didn't quite 
work for me.  The best documentation I could find was wiki-grade.

Given the choice between dealing with the quirks and bugs of someone 
else's (largely undocumented) software, or doing the same for my own, I 
went with the code I knew and knew worked for me.

But I liked how Capistrano was defined as a collection of Rake tasks. 
For better or worse, Rake has the same "market share" as rubygems. 
There are alternatives, and they have their virtues, but using them 
entails additional friction.

So I recrafted my deployment tools as Rake tasks.  And I've done 
something similar for my database schema tools.  As with Capistrano, 
Rails migrations kinda-sorta-but-not-really worked.  And I'd already 
worked out my own basic tools for avoiding the 'discomfort' of bouncing 
in and out of SQL tools.

Now, given that I'm involving people on a Rails project, it would 
perhaps be best to just figure out how to use the "standard" Rails tools 
for utility jobs, but in lieu of that (as it would likely mean spending 
time sorting out issues that are, ultimately, tangential to the 
application itself) using Rake nicely wraps the custom code in a 
familiar UI.

Now, I still write code on my own, largely Nitro (if it's a Web app), 
but given my increasing familiarity with Rake, I have to expect that I 
would use Rake tasks to automate ancillary jobs as well.

Basically, once a tool starts to play a regular role in my projects, the 
burden of employing alternative tools for the same tasks becomes higher; 
I need a compelling reason to go with an alternative.  It has to at 
least do something important that the more mainstream option either 
doesn't do, or doesn't do well.

I have that with Og/Nitro (for many tasks, at least; some are better 
handled by Rails, some by pure hand-rolled code).

What's the argument for Reap?  Is it a "better Rake"?  Is that an 
over-simplification?  Plain wrong?

In writing this I'm reminded of when people look for ways to convince 
their Java-hooked bosses to use Ruby.

So: What's the elevator pitch for Reap?

> Reap's main intention is as a dedicated packaging assistant, and has a
> number of tasks built-in for that. It didn't start out as a general
> task executor at all, but as it evoloved that became more and more
> doable. Now one can actually create a custom task just by dropping the
> code into your project's task/ directory and it will show up when you
> run reap.

I believe Rake allows that, or perhaps it's some Rails thing. But in 
Rails you can drop *.rake files into lib/tasks and file's tasks are 

 > ...
> There are a few more details of course, but that's jist of it anyway.
> Probably those most stark distiction between Rake and Reap, besides
> the stuctural differences is how you prefore the same type of task
> more than once. With Rake you'd define two task with slighly differnt
> names that access common code. Eg. maybe:

When find that I want to perform the same task multiple times I move 
code to plain methods, and call the method from a task.

For example, I had a task that would drop and recreate a database, then 
load in some fixture data.  It initially worked against a single 
database, but later I wanted to be able to sweep all known databases.

I found that I could not loop and call a task more than once, so I just 
moved the task guts to a method.    Simpler all around.

James Britt

"Blanket statements are over-rated"

More information about the Nitro-general mailing list