judo

> Which is why I ended up writing my own mini-ansible which instead runs a remote command executor which can be used to run commands remotely without the session cost. HMU on my email. I've been working on/with this since 2016, and I'd love to discuss: <https://github.com/rollcat/judo>

The pain of Ansible+Jinja2 is what eventually pushed me to write judo[1]... It works surprisingly well for what it was built for, but of course has limitations (e.g. there's no direct support for a templating language; you just plug env variables into a script). The idea is, do less, and allow other tools to fill the gaps. There's still a lot on my todo list, like env files, controlling parallelism, canaries/batches, etc. I'm currently doing these things using hacky shell scripts, which I don't like, so I'd prefer moving that into the main binary. But I still prefer it as-is over Ansible. [1]: https://github.com/rollcat/judo

Personally I prefer the approach that the BSDs took: your OS has a "base" that is designed and integrated as a whole, provides basic services (SSH, httpd, mail, etc) plus a spartan GUI and all the tools to support its own development. Everything else is in ports/packages, which theoretically can be erased all at once with no loss in core functionality. It's conceptually simple and works OK in practice. Notably, macOS (a BSD in my book) took the next logical step and completely sealed the base OS, all the way via logical volume management, verified boot chain, SEP (aka TPM), etc. I agree that NixOS solves configuration management in a much more elegant way, but that elegance carries a heavy cost: it requires domain knowledge to comprehend. Personally I just keep /etc in git, and use judo to propagate changes. <https://github.com/rollcat/ju

Don't get me wrong, I love Python, and I've been a user since the 2.4 days. You brought up plenty of good reasons to use it - and my own rule of thumb is to rewrite a shell script in Python once it goes past 100 lines. My point is that Lua-the-language provides similar expressive power to Python-the-language (including basic stuff like lookup tables), while remaining smaller and simpler to understand than the POSIX shell. It's also simpler to vendor than Python, and you probably want to vendor this kind of stuff to avoid the pain of bootstrapping / circular dependencies. Now I haven't built a build/packaging system like xbps or apk (few people did), but I've been in charge of devops/releng at work for a decade - and if I learned anything at all, it's that it's better to start with the simplest tool that can do the job, and slowly add what