Re: [Fab-user] The list formerly known as fab_hosts

[Jeff Forcier]

http://docs.fabfile.org/usage.html#execution-model :)

Let me know if you still have questions after giving that section a look-see.

-Jeff

On Tue, May 5, 2009 at 9:46 PM, s s <address@hidden> wrote:
> I've just updated my install to the latest version and am converting the
> script I'm working on to the new syntax/semantics.
>
> Used to be you'd do:
>
> config.fab_hosts( "192.168.0.1", "192.168.0.2", )
>
> Then just write your stuff and config.fab_hosts would have each requested
> run() command applied.
>
> Now, it appears that the decorator form is preferred if not required:
>
> @hosts('a', 'b')
>  def my_task():
>     run('ls /var/www')
>     sudo('mkdir /var/www/newsite')
>
> 1> I don't like decorating a command with the hosts against which it it is
> to be applied.  It early-binds the function and, in a dynamic installation
> scenario, that just doesn't make any sense.  I want to have generic
> operations with the hosts against which to apply those operations decided
> dynamically.
>
> 2> It appears that the @hosts decorator doesn't accept a list as a parameter
> as in:
>
> myhosts( "192.168.0.1", "192.168.0.2", )
>
> @hosts(myhosts)
>  def my_task():
>     run('ls /var/www')
>     sudo('mkdir /var/www/newsite')
>
> gives:
>
> TypeError: list objects are unhashable
>
> Number 1 is much more important.
>
> Number 2 is just an issue of something that shouldn't be done in the first
> place not supporting an obvious syntax.
>
> We really need to handle this "hosts" issue right now before a bunch of bad
> code gets written to cover up the fact that using a decorator is just the
> wrong way to handle any part of the "on which hosts do I operate"   issue.
>
> S
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Fab-user mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/fab-user
>