consider adopting the kubectl "plugin" mechanism about openwhisk-client-go HOT 8 OPEN

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

from openwhisk-client-go.

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/?

from openwhisk-client-go.

@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/

from openwhisk-client-go.

You are inventing a plugin mechanism for wsk?

from openwhisk-client-go.

no, just advantaging existing Cobra framework

from openwhisk-client-go.

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.

from openwhisk-client-go.

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

from openwhisk-client-go.

Not yet.

from openwhisk-client-go.