Re: [Fab-user] Virtualenv Use Case

[s s]

On May 2, 2009, at 10:42 AM, Jeff Forcier wrote:

> 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

Yes.  Context managers are 2.5+ but that's fine with me.  You only  
need 2.5 on the deployer i.e. your development machine so I don't  
think this should be too much of a problem.

> 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

Only thing with that is you lose the ability to grab error/status info  
from each command.  One of my other use-cases involves finding out  
whether a command exists on the target machine (wget, for example) and  
installing it if it doesn't.  This involves expanding the error  
handling to perform other actions like:

	run( "wget somefile" ) on error "wget not found" install_wget() and  
retry

Obviously, that's perfect syntax and the Python parser might have to  
be slightly modified to make it work ;-) but you get the idea.

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

I kind of like the idea of a "script runner agent" running the  
commands in sequence and keeping error status for us so we can collect  
error info from each command.

> >  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.

It appears to make a shell, with context, in which there's an 'uber- 
interpreter' available to run cap commands as well as regular shell  
commands but I haven't used it.

S