Re: [Fab-user] env.user and prev_user in the presence of env.hosts

[Jeff Forcier]

On Fri, Apr 15, 2011 at 4:31 PM, Justin Donaldson <address@hidden> wrote:
> Thanks Jeff, didn't catch that bit in the documentation.  I added another
> pull request for your consideration.

Right now we actually organize via Redmine instead of GH -- could you
please make a ticket at code.fabfile.org and put a link to your pull
request? :)

> Well, it's Friday, so here's a half cocked thought:  Could you assign the
> output of one fab request to another as an input?
>
> It would require some special syntax, and some currying.

I recognize the use case but I find the suggested implementation to be
a bit on the confusing/complicated side :(

To help users share data between task functions without doing it all
themselves via env (which is how it should be done now), I think these
are the options:

1) Automatically fill eg env.previous_result with the return value of
task functions. Not much removed from the current "your functions have
to know how to talk to each other by writing/reading your own env
vars" but at least it's a bit cleaner / delimited.

2) Dink around with kwargs in some semi-magical fashion -- your
approach, or an inverse approach where we just add an extra kwarg
(again eg previous_result=<return value>) which has its own set of
pluses/minuses compared to your approach. (I feel it's a little
cleaner on the invoking/task definition end, but also requires gross
metaprogramming re: tasks which do not define this extra kwarg or
**kwargs.)

3) Take advantage of the upcoming move to object-oriented tasks and
have fabric.main simply attach the return value of task1 as an
attribute on task2, which may then opt to access that data as
necessary. Similar to 1) but isn't using a global shared state, only a
per-task-object state -- feels a lot cleaner. We could also do
something with methods here if we wanted, instead of just using
objects as data bags -- many possibilities.

I think 3) makes the most sense -- this would be a new feature
regardless and that seems like by far the cleanest way to implement
it.

> Type errors, etc. for arguments would need to be handled by the authors of
> the fab functions (they would no longer be just strings), but it would
> otherwise mesh with the existing syntax.

Just an FYI that we have half-formed plans regarding the general
problem of task arguments and typing:

    http://code.fabfile.org/issues/show/69


-Jeff

P.S. Going on the road again for the next 4 days so if I am delayed in
replying, that's why =)


-- 
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org