Re: [Fab-user] Beta 1 out

[Jeff Forcier]

2009/7/9 Niklas Lindström <address@hidden>:

> 1. It seems the old issue I had with a command failing to return
> ("tomcat start") is in 0.9b1 but not on master (provided "git-checkout
> 0.9b1" switches to that and "git-checkout master" switches back, which
> is how I tested this).

Can you refresh my memory about this issue? I recall hearing about it
but don't have time to go find the old email right now :(

0.9 and master are still nearly identical right now so it would be
kind of odd for a bug to exist in only one of them -- fwiw.

> 2. I cannot use --roles=<roles> or -R<roles>, but
> <command>:roles=<roles> and @roles works..

Sounds like a bug, will take a look.

> 3. I have to decorate commands with @roles even if they only call
> other commands that are already decorated with @roles. Is this
> intentional/hard to fix?
>
> 4. A thing which worked in the old fabric 0.1, was to call another
> function which sets ``env.hosts`` (actually, I think it only worked
> via @depends).

These are both because of the new execution model, where the host list
(meaning hosts and/or roles) a function runs on is determined at
runtime, *before* entering your function. The best way to work around
this for now is to set env.roles or env.hosts within a function (like
with your #4) but to call that function on the command line and _not_
within another function.

In your example, you need to do "fab setup_a ls_a" and remove the
"setup_a()" call within your "ls_a" function. I do this now to provide
"environments", e.g. "fab staging deploy" or "fab production deploy"
and so on.

If it comes up that there are things you or others need to do that are
not pretty easily solved like above, I may try to reinstate the older
execution model as an option, but for now I'd prefer to keep things
simple as long as it doesn't cause too much heartbreak (so let me know
if it does!)

> 5.  `fabric.contrib.files.exists` fails intermittently (on an ubuntu
> server). I get the feeling it fails to capture the result "in time" or
> something.. Instead, I use ::
>
>        exists = lambda path: not run("test -d %s" % path).failed

If you could dig into this a bit more, I'd really appreciate it. I
don't see why using 'test' would garner consistent results where 'ls'
is somehow intermittent -- they shouldn't be that different. When you
say intermittently, do you mean with the exact same invocation, or
that it works for some inputs but not others?


Thanks for all the feedback :)

Best,
Jeff