Research on plugin root validation approach

[namit-chandwani]

Plugin Research: Root Validation Approach

• Details

  Allow plugins to implement cobra structures and validate them on root.

• Elements that can be validated on root:

  • Flags
  • Environment: Plugins and the host CLI must be built in the exact same environment ie. same golang version, mod dependencies, go path, etc.
  • Overlapping commands: Check if the plugin command overlaps with any existing host command
  • Dependency versions: Any packages outside of the standard library that are used by both the plugin and the host CLI must have matching versions. To tackle this, while distributing the program binary, the developers can specify the exact versions of all dependencies. This can be done by publishing the output of go list -deps -f='{{if not .Standard}}{{.Module}}{{end}}' ./cmd/cli-name into go.mod.

• Structure and Architecture

  I'm currently trying to come up with a set of structure definitions with appropriate data fields which would help us in accomplishing the same.

  Will edit out this part and add them over here in some time.

• POC

  Link (Still WIP)

[ankithans]

so here

• plugins use cobra to create command.
• charmil-core will validate the command and add it to host CLI

In wrapper

• not exposing all the features that cobra provides https://github.com/aerogear/charmil/blob/poc/plugins/calculator/main.go#L12
• cobra works internally, create command func https://github.com/aerogear/charmil/blob/poc/pkg/pluginloader/create.go#L10
• can be made more easy to use than cobra (less hassle on plugin developer's side)

@wtrocki can we decide which way to go? And how validation should work?