I’d like to pitch an idea I’m chewing on recently: Something like Ansible in Zig.
Before I make my pitch, I want to describe what I like and dislike about Ansible, because that makes it easier to explain why I believe Zig would be a great choice to make something better and how that might help Zig.
Ansible is fun to use. Writing up Yaml files with tasks and seeing your servers being set up is great. The inventory is magic, they really did a wonderful job making it intuitive to write up configurations. Ansible has a huge number of built in and community modules for almost everything. Ansible, other than most alternatives works agent-less, meaning that you don’t have an ansible-server running on targets.
That’s the good stuff. Here’s the bad: Ansible requires the target to have a python installation (you may get around it, but practically you need it). Task execution is done by copying over python-tars which is slow and makes debugging impossible. Custom modules may want to use python dependencies, but you really don’t want to install them on targets. The whole module infrastructure is a mess, inconsistent and redundant. As great as the inventory is, it has huge problems with scoping. There is no good way to do logic on task level. Ansible pretends to be declarative, but it’s not.
Why Zig?
Zig has great support for cross compilation. If you need to deploy temporary code on a target to run complex operations (what Ansible does with Ansibalz), Zig can do that so much better. This would especially allow for sane dependency management - dependencies are compiled in, nothing to manage.
Zig can easily create self-contained executables without any runtime dependencies. Great for embedded devices which might not have a python runtime or never saw an update in a decade but still run the show.
Zig is easy to read and write. Maybe not as easy as python, but much easier than Perl or Rust (old and new school choices for such purposes).
Rust’s safe memory argument doesn’t matter for short running operations, scripts can just leak memory (that’s probably not good marketing).
Zig has easy access to C libraries, making a lot of functionality that’s too big to be ported in time easily accessible.
What does Zig get from that?
I see Ansible tasks as a vocabulary. It provides a whole lot of primitives like “create a user”, “copy a file”, “install package”, “add to ssh-host”, “update block in config file”. Having them available in the form of Zig libraries is a huge win, because they have proven to be useful and while they are easy to implement, doing it right is time consuming. That’s exactly what makes python and ansible so sexy.
If there is some coordination between such an Ansible-in-Zig project and the zig standard library, the Zig library could evolve into the most convenient system level development tool. And other than crappy python scripts or yaml tasks that can’t be reused, the result would be highly optimized code that can of course be used outside of automation contexts.
The Ansible task pattern with a check mode (dry-run) could also be a great pattern being used in such a library, especially if it’s combined with transaction support. Something like this is only feasible if it’s part of an early design, and remaking Ansible in Zig would be a great opportunity to do that from the start.
Community catching: There are a whole lot of people working in automation. I did that as a side gig. I love Ansible, but I feel like it’s caught in its history and it can’t really evolve much further. It’s also caught in its corporate context where monetization dictates how it can evolve and that’s making it even slower and less attractive. And yet, this python scripting project gets enormous amounts of community working hours. I would love to see that time being invested in a much more sustainable environment. If such a project would succeed, a lot of that success would stick to Zig. That’s a big “if”, Ansible is strong and it’s hard to establish such a project, but then again, that’s the same for any grass root project.
What’s done
I reserved the domains “zensible.dev” and “zensible.org” to have a place to host stuff and a name. It’s just the domain, no content yet.
Zensible is obviously a reference to Ansible, the sensible Ansible done in Zig (plus some Zen).
Then I have a whole lot of ideas that need writing down and more importantly need to be challenged and discussed. I didn’t have much time lately and nobody to discuss it with, so this is really just an idea in search of some people to brainstorm over it. You’re more than welcome to join if this speaks to you.
