[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fab-user] Virtualenv Use Case

From: Jeff Forcier
Subject: Re: [Fab-user] Virtualenv Use Case
Date: Sat, 2 May 2009 16:47:09 -0400

On Sat, May 2, 2009 at 3:00 PM, Brett Hoerner <address@hidden> wrote:

> I apologize for not reading the code to answer my curiosity.  I poked
> at fab before and was quickly confused. :)

If you looked at it prior to the 0.9 alpha, feel free to look again,
it's been broken out into multiple files and is hopefully easier to
follow now.

At any rate, if you saw Christian's previous email, he goes into some
detail about how SSH/Paramiko work right now, and how we utilize it.
To reiterate, the core problem is that we have to balance two things:

* Convenience: the ability to have a real, honest-to-god multi-command
shell session on the remote end;
* Granularity: the ability to discern, on the local end, the result
(return code, stdout, etc) of each distinct command.

These are unfortunately at odds, as has been implied previously
today/yesterday in a few emails.

I maintain that the best middle-of-the-road approach is to prefix
commands with necessary environment-setup things such as "workon
myvirtualenv", "cd /my/git/repository", or "ENV_VAR=foo", which should
cover a decent amount of use cases.

For use cases which aren't covered by that approach, we can provide an
easy method to build a command chain with "&&", which I think is still
better than an actual multicommand shell invocation. With a shell, you
could e.g. have a failure in the middle of your chain of commands, and
you wouldn't know because the last command exits cleanly and that's
all that is returned. With &&, you still retain state as with a shell,
but but as Christian mentioned, it will "fail fast", stop right away
and return the error code of the first command to fail, which is
almost always the right thing to do in this arena.

Finally, we could even give this feature a switch to turn the "&&"
into ";" for edge cases where you don't WANT fail-fast behavior.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]