Hi,
Ah, I forgot to replace that.
env.workon == 'workon {project}'
The 'workon' command both activates the virtualenv, and moves you to the root of the virtualenv's project (ie: your codebase).
But now that I re-read the part if the docs you linked to, I see my problem: prefix is applied for each command in the context, whereas in my use of it, I am incorrectly expecting it to be applied once, for the scope of the context.
Thanks. 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?
Cheers, Jens
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
|