[Top][All Lists]

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

Re: [Fab-user] Virtualenv Use Case

From: s s
Subject: Re: [Fab-user] Virtualenv Use Case
Date: Sat, 2 May 2009 11:27:55 -0400

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'):

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.


reply via email to

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