Use modules as namespaces about cuisine

[sebastien]

This is a great idea, but we need to discuss further why and how to do it. I really like the object-based approach and the use of context managers, however two points conflict with the initial design of Cuisine:

1. Single-file API (I want cuisine to be compact, not to spread in too many files)
2. Simple C-style API (do not use too complex features so that anyone will feel at home with Cuisine)

One of the reason for that is that cuisine is a mere wrapper around shell scripts, and I don't want to be too clever and introduce a level of complexity. Basically, because cuisine is targetted to sysadmins who know just a little bit of Python (and of course, full-fledged Python programmers) I want to keep things as close to "old-school C style" as possible. It's something I don't usually do but I think it makes sense in this case.

However, we have one problem right now: how to easily write variants for different platforms (for instance, using yum instead of apt-get). Using tests like if platform == "Linux" and dist == "Ubuntu" sounds a bit too cumbersome as opposed to having DebPackage and YumPackage classes that are provide specific exists, insttall, ensure, etc methods.

Another thing to consider is that changing the API would break compatibility with existing scripts -- cuisine is still early, so we can probably affort it, but it's something that we have to carefully think about.

Do you see a particular direction that we should take?

[superbobry]

I like the idea of being as simple as possible, and having one file API is certainly very attractive for use cases you've mentioned in the original README. Here's what I propose:

1. If you ever tried pytest, you probably know that it has a --genscript command, which collects all pytest modules and puts them in a single script, how about we do the same for cuisine? For example, suppose we have a bunch of modules called ssh, file, dir etc, here's what will be available in the generated script:

   file.open()   --> file_open()
   dir.ensure() --> dir_ensure()
   

2. Second option is to provide a high level layer above context managers and objects:

   from cusine.api import file_open, dir_ensure 
   

As for the package managers, I really like puppet's approach using providers -- in fact we can have both providers and platform discovery:

• An abstract provider interface, and a bunch of platform-dependent implementation, AptProvider, YUMProvider etc.
• Runtime distro discovery with platform.linux_distribution()

What do you think?

[sebastien]

I tend to think this would just over-complicate the project, and end up with the mess that Chef is. Overall, I really want to avoid having an API that abstracts various system elements (User,Group,Package,File,etc) -- I want it to simply offer smart functions that have a low-level API/shell scripting feel.

I understrand the temptation to have a more OO approach to the project, but I would restrain from that unless there is no other option. I think we should go with a very simple thing right now, like having an "if" that dispatches to specific implementations depending on the platform, or does-it in place, ie: package_install could delegate to apt_install or yum_install depending on the platform.

This might cause problem in the long run if we have many package mangers supported, but until this happens, it's better to keep things simple, I think.

[superbobry]

Problem is, a bunch of "smart" functions is harder to maintain and modify, at least when compared to the layering approach. Having different API layers allows routine tasks to be done with a few lines of code and makes non-trivial tasks still possible.

Can you please give an example of Chefs "mess"? I've never used it myself, unfortunately.

[sebastien]

Yes, I defninitely agree with that, but I'd prefer to wait and let Cuisine to grow organically -- once the single-file, flat API approach will show its limits, it will be time to move in the direction you pointed out. Just like Fabric, I want cuisine to be minimal and avoid turning into the complicated mess that Chef is.