fab-user
[Top][All Lists]
Advanced

[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 10:42:34 -0400

On Sat, May 2, 2009 at 10:23 AM, s s <address@hidden> wrote:
> Here's one of my use cases that I'd like to get up on the Wiki at some point
> for discussion.

I have this exact sort of thing in mind. I was thinking context managers might
be the best way to do it, e.g.::

    with environment('workon my-new-virtualenv'):
        run('foo')
        run('bar')

Which would, on the remote end, turn into effectively this::

    $ workon my-new-virtualenv && foo
    $ workon my-new-virtualenv && bar

This might need some extension to handle multiple "things", i.e. setting 2
shell env vars and also doing a 'workon', though that can still be done by just
doing ``with environment('FOO=bar BIZ=baz workon my-new-virtualenv')``.

An alternate approach could be something similar to your "shell_commands" bit
below, where we generate a multiline shell command and run it all at once. The
simplest way to do this may be to tweak run()/sudo() to optionally take a list
of strings (instead of a single string) and to then stitch them into a
multiline command.

That would let you dynamically build your commands out of various sub-lists and
so forth, but would keep the API simple. E.g.::

    common_commands = ['workon foo', 'easy_install bar', 'easy_install biz']
    run(['pre_command'] + common_commands + ['post_command'])
    run(['some_other_pre_command'] + common_commands)
    # and so forth

The result would then be something like::

    $ pre_command && workon foo && easy_install bar && easy_install biz

though I would have to think about whether ``&&`` or ``;`` makes more sense for
joining 'lines'.

> I'm not a Capistrano user, only having played with it for a
> little while a few months ago, but it appears that Capistrano partially
> handles this with "cap shell."

I'd have to double check but my assumption was that ``cap shell`` is simply an
interactive way of calling Cap functions like run/sudo/etc, and doesn't keep
state between them. In other words, the point of it is to make it easier to
interactively do "Cap stuff", as opposed to adding this extra stateful
functionality. Again, though, that is only my assumption.


Best,
Jeff




reply via email to

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