On Fri, Apr 15, 2011 at 3:19 PM, Jeff Forcier
<address@hidden> wrote:
Hi Justin,
There's work going on now to make tasks more object oriented, for
example, which will straighten a lot of this out instead of relying on
env to be both informational and for configuration.
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. Maybe it would look like this:
fab foo => bar
foo would return a tuple/list of arguments that could be specified for bar. You could curry the first few arguments, and then perhaps allow for additional arguments:
fab foo => bar:'additional_arg'
the function defs for the second case above would look like:
def foo():
return (1,2,3)
def bar(x,y,z, additional_argument = None):
print('these should be integers!', x,y,z)
return
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. The big benefit is that you could (in some cases) use functions directly from other libraries with no further effort than an import directive.
> The next question is, is there a group of people that are sharing best tips,
> etc. for using fabric on cloud based systems? Is there a better option? I'd
> rather not invent the wheel, or force square pegs in round holes here.
No specific group, but I would definitely welcome discussion on that
here, and it comes up on IRC relatively frequently as well. I'm
personally using more cloud stuff now than I used to, to say nothing
of the increasing amount of user contributions in the same space -- so
improvements should come along relatively quickly.
I'm mixing fabric and libcloud. There's some warts... but it soooo nice to have this sort of control. This feels like it's going to become a staple of a lot of maintenance.