[Nitro] General inquiry about Reap
james_b at neurogami.com
Tue Apr 25 00:01:00 EDT 2006
> 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
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
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.
"Blanket statements are over-rated"
More information about the Nitro-general