Chef-like functionality for Fabric

I'm using Cuisine to deploy an app using both PIP for python packages and NPM for node packages and I'm wondering what your thoughts are on the plan regarding these. Do you write your own methods to ensure these packages in Fabric and use them alongside Cuisine or is this something that should be integrated into Cuisine?

I am currently using and testing Cuisine on CentOS, and have rewritten package commands to use yum instead. Since I'd like to contribute the code back, I was thinking about implementing both for apt-get and yum via some global config and perhaps package abstraction, but then I realized that package_* defs ARE a form of abstraction. So other than if-elif branches, any suggestions how to support more than one package manager?

Hi Sebastien

I've noticed you pushed Sphinx-generated docs to the repo, would you consider hosting it at ReadTheDocs instead? I like this approach for two reasons:

1. It's easy to access from the browser -- Github doesn't preview HTML pages, afaik
2. One can allways build a local copy with sphinx-build

What do you think?

Here are a few commits to give cuisine.py more consistincy and pretty close to PEP8. The biggest ones are the Untabify and teh use 4 spaces for indent. All the others are pretty much dependent on these.

I tried to break up the commits based on the PEP8 section that they applied and have attached any relevant PEP8 link into the commit messages.

Let me know if this is too intrusive.

This set of commits adds tests for some discrepancies between cuisine.run() and fabric.run() in local mode, then adds fixes for those discrepancies. Most changes have to do with wrapping commands the same way that fabric does so that various context managers and env variables get picked up and applied properly.

Great work on this saved me doing something similar. I don't have time right now to provide fixes but wanted to give some feedback on bits that didn't work as I expected.

Installing via pip/easy_install installed 0.0.1 rather than 0.0.4 not sure if this matters as it also didn't work when I tried

from cuisine import *

So I just included the cuisine.py file in the same dir as my fabfile.py and that works great.

As the api docs are a bit lacking I started by using the presentation which is great btw. But then I found that there was a oh-my-zsh plugin at https://github.com/santiycr/oh-my-zsh/ which is a fork of the main oh-my-zsh and there is a pull request to bring the fab plugin into the main repo. I just added https://github.com/santiycr/oh-my-zsh/ as another git remote and merged the changes manually. This makes using cuisine really easy as the tab completion on fab command line now lists all the cuisine tasks and they are named well so its pretty easy to work out which one you want for something.

Anyways great job.

Rather than doing this:

mode_sudo()
# ... do stuff as superuser...
mode_user()
# ... do normal stuff...

It would instead be nice to do this:

with mode_sudo():
    # ... do stuff as superuser...
# ... do normal stuff...

This is more in line with how Fabric does similar things. It would probably be really easy with contextlib.

I can't find any changelog and our code stopped working correctly after upgrade to 0.7.7. It also does not work on 0.7.9.

$ sudo pip install cuisine==0.7.6
$ fab config.prod start
[...] Executing task 'start'
[...] sudo: service service1 start ; true
...
Done.
$ sudo pip install cuisine==0.7.7
$ fab config.prod start
[...] Executing task 'start'
ERROR:root:service1: unrecognized service

like it executes locally, not on remote machine

This is a first attempt to deal with issue #163. Tests with apt, pip and easy_install on Ubuntu 13.10 look fine.

I did not adopt the other package managers to the new model (no testing possible).

The CuisineResult class is not derived from str, as proposed, but implements a str method instead. We need to nail down if this is good enough.

I would expect ssh_authorize to be idempotent, but running it repeatedly results in duplicate keys in .ssh/authorized_keys.

I attempted to rewrite it using something like file_update(keyf, lambda _: text_ensure_line(_, key)) but this produces duplicate lines as well.

When file_write is performed on a system on which 'bzip2' is not installed (like a vanilla Debain Squeeze), it will fail and leave the target file empty. This will also happen when the target file had content before. One way to solve this problem would be to perform package_ensure() on the target system first.

One of the many changes for Fabric 2.x is removal of fabric.api. Maybe we can make cuisine compatible with both by trying to import from .api and falling back to fabric if it fails?

Great tool, thanks!

Function text_ensure_line doesn't add a newline at the end of the text. This is not ideal for e.g. updating configuration files which may need a final newline.

This can be corrected by changing the final line to:

return eol.join(res) + eol

Please consider this. Thanks!

The put() method in fabric honors lcd context, but file_upload() does not. This makes file_upload() fail whenever an lcd context is in place because the either file_upload() code or put() will use the wrong path.

To reproduce this bug just do

cd 'different_local_directory' with lcd('local_directory'): file_upload(target_path, 'some_file_in_local_directory')

The relevant code from put is at fabric/operations.py:364

I'd have written a patch, but the behavior of put() wrt paths is complex enough that it seems wrong to duplicate it in file_upload() w/o refactoring fabric to expose it all for reuse.

1. Modified function process_find to display pid id if the pid is less than 3 digits:

   eg:

['', '416', '?', '00:00:00 udevd'] ['12305', '?', '00:00:00', 'udevd']

After Modifications: ['416', '?', '00:00:00', 'udevd'] ['12305', '?', '00:00:00', 'udevd']

2 . Extended functionality for strace of process eg : cuisine.process_strace(416)

Output:

ERROR:root:Process 416 attached ERROR:root:restart_syscall(<... resuming interrupted call ...>Process 416 detached ERROR:root: <detached ...>