Add support for custom commands

[josegonzalez]

It would be cool if we could somehow implement custom commands. Maybe something like how docker or Hashicorp tooling supports custom commands - either by calling an external binary named spot-$CMD (docker) or running them in a sort of grpc-server manner (hashicorp tools). One could even consider a config file ~somewhere that configured certain commands as calls to particular scripts (so that one binary could implement multiple commands).

My goal here would be to slowly implement the commands I use from ansible as golang binaries and use them with spot, which would make it much simpler to run provisioning against a server in packer (since I wouldn't need to worry about how I'm running my provisioning tooling locally, just install the requisite binaries remotely and we're off).

[umputun]

What would be the difference between calling the external binary as spot-$CMD and calling it as a part of script? The only thing I can think of is such a dedicated command may have some specialized parameters, but without seeing something realistic, it is hard to figure. If you have in mind an example of such a command (i.e. external spot-blah binary), can you show what the desired syntax is, what problem it solves, and how it is better compared to the current script: spot-blah arg1 arg2

My goal here would be to slowly implement the commands I use from ansible as golang binaries

This is exactly what I did too, i.e. made several scripts and several small binaries and using it inside the script

for example, i made a simple script install-pkg.sh and use it like this

  - name: "install curl"
    script: spot-commons/install-pkg.sh curl
    options: {sudo: true}
    cond: "! command -v curl"

[josegonzalez]

I was thinking that the "stronger" syntax around parameters passed to whatever the "module" is would be better than calling a script whose arguments could be specified in any number of manners (depending on who wrote them). For instance, the following is ansible:

- name: Update repositories cache and install "curl" package
  become: true
  ansible.builtin.apt:
    name: curl
    update_cache: yes

And here would be the equivalent in your install-pkg.sh:

  - name: "update repo cache"
    script: apt-get update
    options: {sudo: true}

  - name: "install curl"
    script: spot-commons/install-pkg.sh curl
    options: {sudo: true}
    cond: "! command -v curl"

One could argue that the former is conflating multiple responsibilities, but it's more in line with what folks are used to with ansible.

[umputun]

I'm unsure about this, and I don't think the apt example effectively demonstrates why using a custom module is better. In my past experiences with Ansible, the ansible.builtin.apt module isn't something users create; it's just one of the modules that come with Ansible. Also, the spot equivalent isn't quite right for my situation. If I want to install a package with apt-get, I wouldn't make a custom script; I'd simply use script: apt-get update && apt-get install -y curl and be done with it. The reason I needed this script initially was to install packages universally, for apt-get, yum, and apk-based distributions.

The way Ansible does things never felt right to me. Each module having its own set of parameters means there's a lot to learn and remember. Instead of relying on common Linux commands to achieve goals, you have to learn a special way with Ansible. I aimed to keep spot simple and straightforward, and introducing a special module syntax would go against this idea.

I think Ansible uses modules not to create specialized syntax but to maintain a declarative approach and shield users from complexity. However, Spot is designed to be imperative, making it much easier to write custom scripts.

Regarding your suggestion, it might be worth exploring a way for users to share reusable "scripts". This wouldn't necessarily require new syntax support but rather a method to identify and load such external scripts or apps from a shared location.

[umputun]

moving to discussion as this is not a bug report