consider adopting the kubectl "plugin" mechanism

[starpit]

proposal: adopt kubectl's lightweight plugin mechanism for the openwhisk go cli. it's not even really a plugin mechanism, just a simple dispatcher. kubectl foo works if some executable kubectl-foo is on my PATH. kubectl is agnostic to the impl of kubectl-foo; i.e. it could be another go executable, a nodejs shebang, a bash script, etc.

getting this support into wsk should require only small changes, especially if we can leverage the platform's "which/type" support. i.e.: wsk foo, if not resolved by a built-in command or command subtree "foo" will delegate to the PATH resolver, which does a which foo. if this succeeds, it delegates the command line to an Exec of that resolved /path/to/foo.

kubectl also has a kubectl plugin list, which is a bit more time-intensive, but at the same time not latency sensitive: this one must scan PATH for matching wsk-xxxx executables.

[csantanapr]

I think this is a good thing to add So then I can get “wsk deploy” if I rename wskdeploy to wsk-deploy ! cc @mrutkows @mdeuser

[pritidesai]

sounds like a great idea, @starpit what kind of changes are we anticipating? are you referring to something of this sort: https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/?

[mrutkows]

@starpit I am not opposed to this, but I still view this as a parallel path to what we want to do with making wskdeploy a plug-in of the CLI. See no reason that we cannot have a standalong CLI and a new resource/API for kubectl drawing from the same code eventually. @pritidesai https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/

[starpit]

You are inventing a plugin mechanism for wsk?

[mrutkows]

no, just advantaging existing Cobra framework

[starpit]

sounds like a great idea, @starpit what kind of changes are we anticipating? are you referring to something of this sort: https://kubernetes.io/docs/tasks/extend-kubectl/kubectl-plugins/?

@pritidesai yes, this is what i was referring to. it's an incredibly lightweight approach, and one that allows plugin providers to target multiple CLIs without having to invest anything into the possibly disparate mechanisms (ibmcloud, cobra, etc.) offered by each CLI provider.

[pritidesai]

thats great, have we experimented implementing this kind of setup outside of kubectl?

[starpit]

Not yet.