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.
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 fooworks if some executablekubectl-foois 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
wskshould 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 awhich 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 matchingwsk-xxxxexecutables.