Make the program called for external tools configurable

[salbeira]

We could solve several annoyances - especially for windows users - if we could specify in the decker.yaml what program should be called for certain tasks.

e.g. under Windows, getting rsync for decker publish to work is quite the hassle. If we could let the user specify "decker publish uses wsl rsync" as the base program called several users who already have the WSL activated but do not have something like cwrsync / mingw installed can still make it work.

The same goes for plantuml which I detailed in issue #45 is an intensely frustrating thing to set up on Windows due to how we call the external program.

[monofon]

Sounds like we don't need to let the user specify that, but rather need OS specific calling mechanisms. Or am I missing something?

[salbeira]

Because we have several equally likely methods to do the same thing in Windows (POSIX emulation, WSL, some custom tooling) and a user explicitly asked if he can just change how his program gets called I see no reason to not just put what we currently have hard coded into the default.yaml and let the user change it at will

[monofon]

Nothing, I guess. Want to propose a metadata syntax?

[salbeira]

external:
    <tool>:
        win: string
        nix: string
        mac: string
        options: [string]

Just so the platform specific config is possible for the default yaml.

A user would then do something like:

external:
    rsync:
        win: 'wsl rsync'
    plantuml:
        win: 'java -jar C:\Users\JohnDorian\Applications\plantuml.jar'

Wheras we need to get to an agreement what we do with the publish.rsync.options and the external.rsync.options then.

[monofon]

What about argument positions for input and output? Does the assumption that the last two arguments are input and output files hold for all intended use cases?

[monofon]

Apopos rsync.

Rsync options are currently handled in publish.rsync.

[salbeira]

What about argument positions for input and output? Does the assumption that the last two arguments are input and output files hold for all intended use cases?

Good question ... do we assume otherwise in our other current calls to external programs? If not I do not see an issue. Otherwise what about allowing printf like syntax like "program %i -o %o" or something? Just spitballing here.

Apopos rsync.

Rsync options are currently handled in publish.rsync.

That is what I said in the last line of my previous comment 😄 We can either merge the option lists of the two or let an explicit declaration of publish.rsync.options overwrite the external.rsync.options to keep current behaviour.

[monofon]

You cannot expect me to actually read everything you write. :grin: