apache / apache/openwhisk-client-go

consider adopting the kubectl "plugin" mechanism

Open
#110 8 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
37
Forks
44
PR merge metrics
No merged PRs in 30d

Description

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.

Contributor guide

Open the contributing guide

Research direction

The issue names no files or tests; start at the wsk command dispatcher and inspect how built-in commands and command subtrees are resolved. Check how the platform's which/type support could locate executables on PATH, then define completion as delegation of unresolved commands and PATH scanning for matching wsk-xxxx executables.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
cli
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.