Compiled custom binary export

[soullivaneuh]

Is your feature request related to a problem? Please describe.

I'm really interested about your CLI metadata feature, giving me the possibility to create a good QoL boosted cli tool with ease, and thanks for that! 👍

But the current solution has some lack in my opinion:

• You must setup an alias to a tusk command. It may be not easier to anybody not familiar with the Linux CLI env.
• You are dependent of a tusk.yml configuration file. The user will have to get the configuration file manually or via a custom script. It's kind of a TOIL thing.

Describe the solution you'd like

I would like the possibility to "compile" a dependencies/configuration free binary to be ready to use "out of the box" without having to deal with the go language.

Something like that:

$ tusk -f /path/to/tusk.yml --export=mycli
$ ./my-cli
mycli - A custom aliased command-line application

Usage:
  mycli [global options] <task> [task options]

Tasks:
  ...

Would not it be awesome?! 😄

Additional context

I'm currently not a Go expert, but I might thing this is gonna help : https://github.com/gobuffalo/packr/tree/master/v2

If you think this as no place to take on tusk, a cook book may be written instead.

Regards

[rliebz]

Love the idea, but I'm not sure that there's a good way to do what you're describing.

Anything that bakes metadata into the executable itself (like with packr) means re-building from source. That's almost certainly going to be tougher from an environment setup perspective than a shell alias—I don't think tusk could expose binary building from CLI without bringing the entire go toolchain along. As it stands, there's actually nothing Go-specific about the Tusk CLI tool once it's built.

I'd also argue that sharing a tusk.yml is easier than sharing binaries across machines. With a tusk.yml, you can upgrade the Tusk CLI without rebuilding the custom CLI, and you don't have to worry about different operating systems or architectures, because the current installation methods have that covered.

I'm happy to leave the issue open in case we can figure out a clean way to do this, but my intuition is that a shell alias is probably as easy as it's possible to be.