Suppose one has a computing environment, in linux, which is static and persistent. I have one-way ssh connections, and the infrastructure is trusted -- it is mine.
There exist a variety of branded "enterprise" tools, such as ansible, which come with pre-canned routines. Ultimately, if one wants to modify them, they are a pain.
Next, you have your airflows (dags) and Luigis (gnu-make clone in python; python is a lower level language than make and bash, with no application binary interface support, unlike make). These are a pain in the sense that one has to write low level code for high level tasks (python has become a low level language with a typing problem and versioning problem), and you have to deal with the python baggage (the virtual env/anaconda/cross-platform interop) in order to use anything.
All around these "products," schemes, and tools, there exists the native unix/linux operating systems and docker images that "just work."
Inside these docker images and subsystems (windows subsystem for linux), you have all these tools that "just work," including the 50 year old project, "Make", and zsh/bash alongside parallel and ssh.
make is in fact totally generic, and when I would like to write up some quick automation, it is far and away faster than anything I could do in, say, a week or two with luigi/airflow. It also serves as a way to identify new tools: if something gets too complicated, clearly it should be a packed tool in a lower level languaue.
Further, I do not incur any fixed costs related to dragging around the python pile of dependencies across different linux distributions and windows.
However, there seems to be a missing tile: make's effectiveness weakens the moment I would like to automate a task that runs on a remote box. I have tried ssh -c "..." but it wound up being a bit of a kludge.
In the search for a workaround, I encountered pachyderm (data science data versioning), luigi (make clone), airflow (not fun), ansible (again: tinkery python-based time sink), and perhaps there are others.
I also ran into a tool from the 1980s/90s known as expect and autoexpect. This tool seems to be native to linux, and falls into the "just works" category on windows subsystem for linux, cygwin, my remote linux machines, etc.
It seems to fit the bill, and better yet it plays well with my make-style approach to automation. I am, in general, completely ok with the automation.exp scripts being noisy on the inside, as they are automatically generated. The important part is that the human created components -- the little components.exp fit together without kludge-y nonsense (all the flow control, configuration, user logins, documentation, and installation baggage associated with new-age tools).
However, autoexpect is a macro-recorder, and a lot of what you might want to do with it involves non-deterministic responses from the remote machine. This poses a problem, unless you take the time to become an expect expert.
Shoving aside all the preamble, I was curious: are there alternatives to autoexpect that also fall into the "just" works category across these systems?
And, to limit the obvious, not looking for my automation system to require me to lug around machinery to install and maintain python virtual environments -- sick of dealing with that mess.