Re: [Fab-user] Unexpected results using multiple context managers and virtualenvwrapper

[Jens Rantil]

Hi Paul,

I have not worked with virtualenvwrapper myself, but maybe can give you some input.

First off, what does `env.workon` contain? Also, have you seen the example for virtualenvwrapper in the documentation[1]? Maybe ti could be of any help?

[1] http://docs.fabfile.org/en/1.8/api/core/context_managers.html?highlight=workon#fabric.context_managers.prefix

Cheers,

Jens

On 2 dec 2013, at 23:05, Paul Walsh <address@hidden> wrote:

The examples for nested context managers in the docs (http://docs.fabfile.org/en/1.8/api/core/context_managers.html) demonstrate with virtualenvwrapper.

My code in question also uses virtualenvwrapper, but the results are unexpected:

for example, when my virtualenv project root is:

/srv/project/


And I have a Fabric task like so:

@task
def clone():
   utilities.notify(u'Cloning the data repository.')

   with prefix(env.workon), cd(/srv/project/tmp):
       run(#DO SOMETHING)

I expect the run command to be executed in /srv/project/tmp, but it is executed in /srv/project - the venv root.

Changing the order, makes no difference. Nor does nesting like so:

@task
def clone():
   utilities.notify(u'Cloning the data repository.')

   with prefix(env.workon):
with cd(/srv/project/tmp):
          run(#DO SOMETHING)


Why does any context manager where I activate a virtualenv, *always* put me at the root of the virtualenv, seemingly ignoring the other arguments for my context?

I'm on Fabric 1.8



_______________________________________________
Fab-user mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fab-user

signature.asc
Description: Message signed with OpenPGP using GPGMail