[Nitro] General inquiry about Reap
transfire at gmail.com
Tue Apr 25 00:34:43 EDT 2006
On 4/25/06, James Britt <james_b at neurogami.com> wrote:
> 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.
Very good points. Thanks James. The transition to yet another tool is
understandably steep. And has to be worth the effort. I would like to
lower the bar as much as possible while increasing the worth of
corssing over at the same time.
At one point Reap actually went through a phase of being just a set or
Rake tasks. But it lacked a little bit for it, so I decided against
that route. Nonethless I'm asking partly b/c I am wondering about
making it, at least, more like Rake.
Note you can already use Reap via Rake just as if Reap were nothing
but a set of tasks --I just created Rake interfaces for each Reap
task. It wasn;t hard. But I find it more trouble than it's worth. Why
create a Rakefile when you already have the tasks availabe to you just
by calling reap?
> So: What's the elevator pitch for Reap?
Well, first understand Reap's core intent is like that of Meta Project
(if you've heard of that project) --a project assitant that makes it
easy to do many of the common chores. For instance Reap makes it
pretty easy to generate .tar.gz, .gem and .deb packages in one fell
swoop. Another intersting task is it's ability to extract unit tests
from source comments. It also has a testing task that has very nice
output and isolates each test in it's own process. And it will release
to Rubyforge right easy too. Plus others. So that's one thing. Like I
said the ability to create cusotm tasks simply evolved out the
dedicated tasks I was building, and it's still evolving, but wan't the
But the main thing that really sets Reap apart is the ProjectInfo
file. It's a YAML file that describes the project and how things need
to be handled for it. In this way there's a single resource for all
this information that can reused by any task. And becuase it is pure
data and not Ruby code, that information is available in a very clear
and descernable way to any other tool, or human for that matter.
Do check out the webpage (albiet still a bit rough).
More information about the Nitro-general