Added a way to extend dstask without cluttering the core

[cgardner]

This was inspired by the way git allows you to add sub-commands using the git-command convention and run the command using git command. This is a very primitive version of that.

It'll also allow us to develop tools (gantt charts?) without cluttering up the core application.

[Dieterbe]

if you have a binary git-command why would you want to run it as git command ?

[cgardner]

if you have a binary git-command why would you want to run it as git command ?

For me, it fits nicely into the workflow and will work with any shortcuts you have set up. For example, I have aliases for git (g) and dstask (,t). Rather than remembering that there are two ways to do it, I can use my alias to fit my workflow.

[naggie]

Definitely an interesting idea to extend dstask. I think this needs to be driven by specific use cases, like the importer.

We could also consider some interoperability requirements, so dstask can discover these cmdlets and query them for what they do; another possible justification for this mechanism.

[dontlaugh]

Prior art here is the Hashicorp suite of products, and they have one more layer of sophistication. The binary naming scheme for several of their products lets you specify a type. For the Packer machine image builder, for instance:

packer-${type}-${pluginname}

Examples of the "builder" and "provisioner" type:

• https://github.com/solo-io/packer-builder-arm-image
• https://github.com/dontlaugh/packer-provisioner-deno

So for the dstask plugin type that creates a new subcommand, we might prefer a naming scheme that embeds the "cmd" or "subcmd" string to indicate a type:

dstask-cmd-foo

This leaves open the possibility of specifying other types, which we have discussed in the past.

dstask-precommit-foo
dstask-output-blah

If we do not adopt this convention early, it might be harder to disambiguate later.