Re: [Fab-user] road to 0.1.0

[Christian Vest Hansen]

I don't plan on tackling it, but the way I had imagined it to work,
was like #1. The kwargs could be strings to name variables where the
output would be stored, in which case it'd behave like #1a, or
file-like objects (such as StringIO) and then behave like #1b. And
under the covers, the string-with-variable-name way would be
implemented with a file-like object that split the input into a
StringIO object in HostConnection.host_local_env (or ENV in the case
of local), and sys.stdout and sys.stderr.

I'm not really sure how capture in capistrano works. On the surface,
it looks like run, except it returns stdout of the first host - which
dosn't sound particularly clever to me.

Still, if it ends up in the host_local_envs, then there's no way to
get() it either.

Hmm... this one's a tough cookie. #3 might indeed be the best way to
do it. But if we return stdout as a string, which host do we return it
from?

I can't think of the Right Way to crack this one.

On 7/12/08, Jeff Forcier <address@hidden> wrote:
> > 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
>


-- 
Venlig hilsen / Kind regards,
Christian Vest Hansen.