sebastien/cuisine — Issue #40: Standardize mode_xxx, sudo, run, local and make it thread safe
Author: schacki
Created: 2012-02-07 10:33:31+00:00
State: open

There are currently 4 mode functions(=mode_local, mode_remote, mode_sudo, mode_user) and 4 global mode variables (=MODE_USER,MODE_LOCAL, MODE_SUDO, MODE) , 3 cuisine execution functions (run, sudo, run_local) and the 3 native fabric execution functions (run, sudo, local).

Some of these have different APIs, but similar functionality. E.g. model_local and mode_sudo both influence the very basic behaviour of the run function. But mode_sudo uses/implements the "with" API and manipulates a global variable to control the behavior, while mode_local manipulates the module itself.

Some of these just overwrite and wrap the fabric native functions without changing the functionality like sudo, while others change the functionality significantly like run.

One global variable is boolean (mode_local), while others are strings(mode_sudo).

At the moment I do not get my head around it, why these complexities are necessary and why we cannot standardize all that and make it more simple. I am aware that I currently might not fully understand this complete beast and that whatever kind of changes we possibly apply here, this has a major effect.

So let me sketch some preliminary ideas here, to make my thoughts clearer, but also hopefully as a basis for further discussions around this topic:

1. Standardize on exactly 1 execution function
Implement ONE cuisine run function. This run function checks fabric.api.env for certain variables. Based on the results of fabric.api.env, a certain excecution behavior will be enforced (e.g. run local with sudo, or run remote as current user, etc). And this is the only place where this complete set of behaviors is controlled.

2. Control User/Sudo
a) 1 boolean env variable env.MODE_SUDO=True|False will determine, if sudo is used in the run function or not.
b) The current mode_sudo and mode_user classes are used to controll env.MODE_SUDO

3. Controll Local/Remote
a) 1 boolean env variable env.MODE_LOCAL=True|False will determine, if statements are executed on the local ore remote machine.
b) 2 new classes mode_local and model_remote including the __enter__/__exit__ API are used to controll env.MODE_LOCAL

4. I personally would set env.MODE_LOCAL=False and env.MODE_SUDO=False as defaults.

Looking forward to your feedback. I am happy to contribute any code along those lines.
Juergen