Re: [Fab-user] road to 0.1.0

[Jeff Forcier]

> Have you had the oppotunity to look at this #12?

I have, and the only reason I haven't actually committed any patch to
my Github yet is that when I was last investigating it (earlier in the
week) I was crippled by indecision (what a surprise!) :) I could've
just dashed out "something that works" but I really want to do things
the right way from the get-go.

Basically, I could see capturing output happening a few different ways:

1) Extra kwargs in run/sudo/etc, namely 'stdout' and 'stderr' so one
can capture either/both, whose values are strings to be used as ENV
keys:

    run("foo", stdout="foo_stdout")
    result = get("foo_stdout")
    # do stuff with result

Question is, print stdout/stderr as run/sudo currently do (option 1a),
or to hide that output as if the capturing is "consuming" it (1b)? The
printing code starts to get a bit messy if you want to both print
*and* store. Capturing and not printing at all would make this easier,
I think. But I'm not sure if that's the best behavior from a user
standpoint. (We could also add verbosity arguments -- I was thinking
of doing that globally anyways -- but that's a different story).

2) Create a new 'capture' operation which encapsulates the behavior of
#1, but without the expectation of printing any output -- just capture
it. Would need a 'via' argument specifying whether to run the command
normally, with sudo, or locally.

3) Have run/sudo/capture/etc return the output of the command if it
ran successfully. This could require reworking how Fabric executes
operations (given the indirect nature of that execution), which is why
I haven't jumped on it already -- IMO it's the best approach to take
from a user perspective:

    result = run("foo")
    # do stuff with result

Also, how to handle the stdout/stderr duality -- return a two-tuple?
Return only stdout or stderr (controlled via arg) but never both?
Capistrano's capture() returns stdout and prints any stderr, which
might be the best approach.


Given all that, my instinct is to go after #3 (or #1b if that fails),
and that tweaking run/sudo/local instead of creating a capture() is
the more Pythonic way to go.

I'll pick this back up today, hopefully, so please drop me a quick
line if you start tackling it yourself :)

Regards,
Jeff