Distributing kui plugins via krew

Describe the topic Distributing kui plugins via krew.

This topic was discussed twice during SIG-CLI meetings with a small demo on Oct 9.

Kui plugins should be lightweight in that not every UI plugin installs its own electron/chromium dependencies. For that they need some dependency management on the kui side. The idea is to have a helper (?kask?) which takes care of providing runtime dependencies for UI plugins. The plugins themselves can then be rather slim and install just the bundle of node_modules and program logic. (please correct me, if I got something wrong here).

Kui developers raised the idea that those plugins could be distributed via krew. So let’s talk about what are the requirements that kui has for plugin management. This will help krew understand what would be needed to support this use-case. Also, there may be some easy steps to be taken by krew to unblock further development on kui side.

[starpit]

kask itself would be under the management of krew. the chain-installed kui-base would not be under krew’s management, but rather managed by kask.

it is a trade-off we can explore. i want to keep the discussion open, for now, because there are foreseeable (but possibly ignoreable) issues with having one chromium per plugin; e.g. every plugin launch would add a separate icon to the macOS dock

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community. /close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.