Embed shell completion scripts in binary, provide `completion` subcommand

[dontlaugh]

This would be a nice feature, imo. I like it when binary tools provide a subcommand to print shell completion functions to stdout.

For example, see this help text from kubectl completion -h

  # Load the kubectl completion code for zsh[1] into the current shell
  source <(kubectl completion zsh)
  # Set the kubectl completion code for zsh[1] to autoload on startup
  kubectl completion zsh > "${fpath[1]}/_kubectl"

Packagers who want to deal with script files could still have access to them.

This is easiest when you use Go 1.16 or higher. Prior to Go 1.16, you need an extra build config.

[naggie]

Good idea! It could ingest from https://github.com/naggie/dstask/blob/master/.dstask-zsh-completions.sh and https://github.com/naggie/dstask/blob/master/.dstask-bash-completions.sh at build time even.

https://github.com/naggie/goblinpack may be a good zero dependency way of doing this.

[dontlaugh]

Keeping the scripts on disk as separate files is nice for inspecting, testing and editing. So I'm thinking we will need to do one of the following to embed

1. Write a make recipe to to generate go files that embed the scripts as strings. When a script is edited, make picks it up and regenerates the file.
2. Use a binary-embedding tool like your goblinpack. However, this might increase the burden on package maintainers to have another tool present at build time.
3. Upgrade to Go 1.16 and use the new built-in binary embedding features

I think 2 might be kind of a big deal for some of the package maintainers. I haven't asked any of them, though.

3 is what I'd prefer, because it requires no generate step, or changes to build scripts at all. And I think most operating systems have go 1.16+ in their standard repositories. I think this is the case for FreeBSD, and I know this is the case for Ubuntu 20.04+ and Arch, of course.

1 is the most portable and doesn't require new tools or upgrading Go. Just some updates to make.

Is there any reason we can't upgrade our Go version in go.mod?

[naggie]

Oh, I had no idea about (3) -- that's much better! No reason to not upgrade.

[dontlaugh]

I've open #163 with just the Go upgrade to start.

[Dieterbe]

sounds nice. is there any reason why the file being emitted (or printed at runtime) might be different from the original source file ? e.g. "template variables" like paths to installed files might be different at runtime. Not sure.. ? if we can't guarantee identicalness (?) then we should probably make that clear to packagers.

[dontlaugh]

I've opened a draft PR for this #165

[dontlaugh]

https://github.com/flipee/pkgbuilds/blob/master/dstask/PKGBUILD

@flipee I believe I've constructed #165 so you won't need to make any changes to your installation script, as long as install follows symlinks, that is. The script files are the same, I've just 1. moved them into a completions subdirectory, 2. left symlinks at the original locations for both bash and zsh scripts, and 3. embedded these scripts directly in the binary

[flipee]

Hey! Thanks for letting me know. I think we can just move on and get the completions from the subcommand output. It's okay to do this in PKGBUILD.