apache
consider adopting the kubectl "plugin" mechanism
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.
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
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/?
@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/
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.
thats great, have we experimented implementing this kind of setup outside of kubectl?