Charmil as wrapper for cobra

[ankithans]

Wrapper POC

Provide wrapper structure without any strong dependency on Cobra. Plugin Core based of those structures build cobra command.

Architecture & Working

1. An Host CLI in which commands need to be embedded
2. A Minimal YAML file defining the commands of the plugin CLI.

   commands:
   - 
       name: COMMAND_NAME
       mapsTo:
           name: INITIAL_NAME
           subcommand: SUBCOMMAND_NAME
           args:
               - ARGUMENT_1
               - ARGUMENT_2
       shortDescription: "description of command"
       usage: '
       Explain the usage of the command in host CLI
       $ HOST_NAME COMMAND_NAME ARGUMENT_1
       $ HOST_NAME COMMAND_NAME ARGUMENT_2
       '
       flags:
           # define flags

3. Plugin Structure to extract the plugin commands, args, flags etc. defined in YAML file
4. Plugin Loader to load the YAML and create cobra command in the Host (provides common API for host and extensions to use)

pros

• Access to huge market. We can onboard all the CLI's into this framework no matter they are made with golang, bash, python etc.
• Easy onboarding of plugins. A minimal configuration yaml file to be made, providing the details about using the commands, arguments and flags.
• While creating the yaml file for plugins, we are indirectly documenting the plugin

challenges

• Wrapping the binaries may give performance issues
• Assuming that user's system has CLI installed which is to be embedded (we should be able to solve this)
• We can use CLI's binary to solve above issue
• Some CLI's will only be available for specific operating systems

reference - https://github.com/aerogear/charmil/blob/wrapper-poc/working-group/wrapper_poc.md

I was just playing around to figure out the issues I faced in pluginloader (issues)
So POC is still pending but I am on it
created yarn add command and embedded it into host - https://github.com/aerogear/charmil/blob/wrapper-poc/pkg/pluginloader/loader.go

[wtrocki]

not sure how YAML file will work with arguments or validators. Argument definition is typically linked to some structure for example:

https://github.com/redhat-developer/app-services-cli/blob/main/pkg/cmd/cluster/connect/connect.go#L58

Also introducing yaml format at this phase seems excessive. We can define structure and as bonus make it redable and writable as yaml/json later.
Challenge here is more what to expose :)

Wrapping the binaries may give performance issues

Oh..no! Waiting another 2ms for command execution is too much for me to handle.

Access to huge market. We can onboard all the CLI's into this framework no matter they are made with golang, bash, python etc.

Not getting it. How this will work for non golang code

Easy onboarding of plugins. A minimal configuration yaml file to be made

Questionable. Working with untyped yaml file vs golang structure. Golang is much better

While creating the yaml file for plugins, we are indirectly documenting the plugin

Eghm..

https://chromium.googlesource.com/external/github.com/spf13/cobra/+/HEAD/doc/md_docs.md

Lets keep pros and cons for later

[wtrocki]

I think we need to reduce scope here as I see lots of bonuses like yaml or support for non golang executables (which surely can be implemented later)
Core concept for this poc is to build and validate feasibility of wrapper around crazy amount of cobra options without limiting plugin creators.

[ankithans]

Challenge here is more what to expose

Here is the basic command structure, generally command will posess these options! I need to research more by deep diving into cobra command structure, for including/excluding more options.

type PluginConfig struct {
	Commands []CommandConfig
}

type CommandConfig struct {
	Name             string      
	MapsTo           ArgsConfig
	Flags            []FlagConfig
	ShortDescription string 
	Examples         string      
}

type ArgsConfig struct {
	Name       string
	Subcommand string
	Args       []string
}

type FlagConfig struct {
	Type         string
	DefaultValue string 
	Name         string 
	MapsTo       string 
	Description  string 
	Alias        string 
}

Access to huge market. We can onboard all the CLI's into this framework no matter they are made with Golang, bash, python etc.
Not getting it. How this will work for non Golang code

Okay so let's consider yarn which made in javascript. For this POC we just need the CLI (in this case yarn) to be installed (or executable binary). And we can create a cobra command by mapping the actual command, subcommand and args.
Here is an example of yarn add PACKAGE_NAME1 PACKAGE_NAME2 PACKAGE_NAME3

var InstallCmd = &cobra.Command{
	Use:   "install",
	Short: "install a package",
	Long:  ``,
	RunE: func(cmd *cobra.Command, args []string) error {
		fmt.Println("Install command called")

		args = append([]string{"add"}, args...)
		fmt.Println(args)

		c := exec.Command("yarn", args...)
		c.Stdin = os.Stdin
		c.Stdout = os.Stdout
		var buf bytes.Buffer
		c.Stderr = io.MultiWriter(os.Stderr, &buf)

		return c.Run()
	},
}

Oh no! Waiting another 2ms for command execution is too much for me to handle.

😅😅

Easy onboarding of plugins. A minimal configuration yaml file to be made
Questionable. Working with untyped yaml file vs Golang structure. Golang is much better

Like internally we will always have a golang struct. I was saying here in the prespective of plugin creator. He can use the YAML to define commands, flags etc, later we can validate them while loading into host.

https://chromium.googlesource.com/external/github.com/spf13/cobra/+/HEAD/doc/md_docs.md

Absolutely the finest way!

I think we need to reduce scope here as I see lots of bonuses like yaml or support for non golang executables (which surely can be implemented later)

agreed!

[wtrocki]

Okay so let's consider yarn which made in javascript

Sure. It is clear that wrapper makes that possible. Not sure if we should just talk about this at this phase :D

Overall great work!