tricorder VS z-run

There is https://pyinfra.com/

As a sidenote, I also made a small experiment a while ago : https://github.com/linkdd/tricorder/

But it's a bit of a chicken-and-egg problem. Without users, I don't know how it should be used, without features I won't get any users. So for now, it's in a state of "I'll address bug reports and feature requests, but I won't actively develop it".

Thank you. Your library seems nice.

Unfortunately, I have to say it... I hate YAML with a passion, k8s, github actions/gitlab ci, ansible, etc... When I'm doing ops jobs, I feel like I'm coding in YAML.

Btw, this hate for YAML birthed https://linkdd.github.io/tricorder/ :P

Another one in the same vein is tricorder, which has one of the coolest websites ever. AFAIK it doesn't do dependencies, though. But it's got a RUST API!

I couldn't agree more with you about Ansible... I've started using Ansible in two projects, and I think it was enough for me... Ansible is perhaps great when you have granular tasks, that maybe don't need to communicate between them, or perhaps that don't have too much logic (or worse loops). However, as soon as your Ansible "scripts" start becoming actual "scripts", everything gets out of hand... (Also the performance is terrible due to the fact that each task is "bundled" on the host, copied remotely, extracted, executed, deleted, repeat for each and every instance of the same task...)

----

Now about your `tricorder`, by looking at the readme, I gather it just allows one to run the same command over multiple hosts (filtered by name or tag), but nothing beyond that? How could one run for example a pipeline of tools on the remote hosts? (I assume `bash -c 'tool-1 | tool-2'`, but with careful escaping?)

Perhaps a first step towards actually being an "Ansible replacement" would be to bring back in some "scripting" ability. For example instead of giving each command as arguments, there could be a "library of scripts", and the user can choose one of those to run on each remote host. Then those scripts could be written in whatever language the user chooses (`bash`, Python, Ruby, etc.)

Also, with regard to the "library of scripts", one thing that Ansible got right is the possibility to put multiple different tasks in the same file, thus one doesn't need 20 files for 20 small tasks, but instead these can be put inside the same YAML file.

----

For example this is how I did it in my own "Ansible replacement", <https://github.com/volution/z-run>, like for example, one can write something like these snippets: <https://github.com/volution/z-run/blob/development/examples/...> (see `ssh / launch / simple` that runs locally which just calls `z-run ssh "${_target}" ':: ssh / remote / main' "${@}"`, which is in itself a non trivial `bash` script, one that will run remotely.)

In the end, what I think we need, is a tool to easily run "scripts" on a remote system, but make it as easy to use as it would be on the local machine. (Sort of like the RPC but across SSH and for scripts.)

Good point!

I'll add to that READMEs, LICENSEs, SBOMs (Software Bill of Materials), example configuration files, etc. How to supply all those files when all one gets is a single binary executable?

Simple! Bundle everything in the executable.

As a bonus, because the tool outputs these files, it can now generated them dynamically. For example instead of a bland configuration file, with all the possible integrations commented out, it could either try to auto-detect where it's running and what's available, or present the user with a question-answer session to fill in the details.

----

For example, a pet project of mine <https://github.com/volution/z-run>:

z-run --readme # shows the README with `less` (if on TTY) or to `stdout`

z-run --readme-html # for the HTML version to be opened in `lynx`

z-run --manual # or --manual-man or --manual-html

z-run --sbom # or --sbom-json or --sbom-html

It even gives you the source code:

z-run --sources-cpio | cpio -t

So, does your tool need a `.desktop` file? Just create a flag for that.

Or, if there are too many such extra files needed to be placed wherever provide an `--extras-cpio` and dump them as an archive, or if placing them requires some work, provide an `--extras-install`, but before `sudo`, kindly ask the user for permission.

Granted all this requires some extra work, and increases the bulkiness of the executable, but:

* all that extra code can be extracted into a common library; (I intend to do that for my software;)

* if all these are compressed, especially being text-only, they are a fraction of the final executable;

----

I am especially proud of the `--sources-cpio` option. Is something broken with a particular version of the tool that you rely on? Great, instead of bumbling around GitHub to find the particular commit that was used to build this particular version, I can just get the sources from my tool and use those. All I need is the build tools, which in case of Go is another `.tar.gz`.