Introduce CLI and logging library

[ccremer]

Summary

• Introduces CLI library to help getting started with flags and other configs
• Introduces Logging library

Checklist

• Categorize the PR by setting a good title and adding one of the labels:
  bug, enhancement, documentation, change, breaking, dependency
  as they show up in the changelog
• Update tests.

[ccremer]

The default help text looks something like

NAME:
   go-bootstrap - a generic bootstrapping project

USAGE:
   main [global options] command [command options] [arguments...]

VERSION:
   unknown

COMMANDS:
   example  Start example command
   help, h  Shows a list of commands or help for one command

GLOBAL OPTIONS:
   --debug, --verbose, -d  sets the log level to debug (default: false) [$BOOTSTRAP_DEBUG]
   --help, -h              show help (default: false)
   --version, -v           print the version (default: false)

Running subcommand with go run main.go example --flag bar yields

2022-01-06T12:22:56.976+0100	INFO	go-bootstrap	Starting up go-bootstrap	{"version": "unknown", "date": "2022-01-06", "commit": "-dirty-", "go_os": "linux", "go_arch": "amd64", "go_version": "go1.17.5", "uid": 1000, "gid": 1000}
2022-01-06T12:22:56.976+0100	INFO	go-bootstrap.example	Hello from example command!	{"config": {"ExampleFlag":"bar"}}

[glrf]

LGTM. A bit over-engineered for my taste. I don't think most controllers and similar need a full blown CLI library, but 🤷

My 2 cents, but nothing I have too strong opinions on:

• I'm not a huge fan of using cmd/ directory as anything else then containing main entry-points. I know multiple CLI libraries suggest that but it still confuses me when I see it
• I'm not a fan of the global config variable.
• Pretty much all K8s projects use cobra and we'll most likely have it in our transitive dependencies anyway. I know a lot of people somehow don't like cobra, but are there good reasons not to use it?

[ccremer]

* I'm not a huge fan of using `cmd/` directory as anything else then containing `main` entry-points. I know multiple CLI libraries suggest that but it still confuses me when I see it

Do you have an alternative structure suggestion?
Bear in mind, it's not intended to have actual business logic in cmd/, but as you correctly assumed, just the entry points. See an example in K8up, where k8up operator is the entrypoint, but actual controller logic is in other packages: https://github.com/k8up-io/k8up/blob/master/cmd/operator/main.go

* I'm not a fan of the global config variable.

Yeah, I'm not that much fan of singletons either, but here I compromised.
Is adding a Config instance to the CLI context like AppLogger(c) a viable alternative?
The config instance can then be retrived and passed around to subcommand entrypoints.

* Pretty much all K8s projects use cobra and we'll most likely have it in our transitive dependencies anyway. I know a lot of people somehow don't like cobra, but are there good reasons not to use it?

I disagree with the statement that all K8s use cobra and for me that isn't a good enough reason to use a specific lib, especially since their versions might differ anyway. I mean also a lot of K8s projects use either klog or zap so they're already not even using the same logging framework 🤷

[glrf]

Do you have an alternative structure suggestion? Bear in mind, it's not intended to have actual business logic in cmd/, but as you correctly assumed, just the entry points. See an example in K8up, where k8up operator is the entrypoint, but actual controller logic is in other packages: https://github.com/k8up-io/k8up/blob/master/cmd/operator/main.go

I personally find the k8up example even more confusing. It's called main but it's actually not a main package. I personally like to keep the hierarchy flat. So I would probably keep the command structs in the main package and not over complicate it. But calling it command instead of cmd would help me for example

Yeah, I'm not that much fan of singletons either, but here I compromised. Is adding a Config instance to the CLI context like AppLogger(c) a viable alternative? The config instance can then be retrived and passed around to subcommand entrypoints.

What I personally often do (and copied from kubectl) is to define the actual executing function (So in this case main(c *cli.Context) error) as a method on an option struct. So basically:

type exampleOption struct {
  ExampleFlag string
}

func NewExampleCommand() *cli.Command {
  o := exampleOption{}
  Command = &cli.Command{
     Name:   "example",
     Usage:  "Start example command",
    Action: o.main,
    Flags: []cli.Flag{
	&cli.StringFlag{Destination: &o.ExampleFlag, Name: "flag", EnvVars: []string{cfg.Env("EXAMPLE_FLAG")}, Value: "foo", Usage: "an demonstration how to configure the subcommand"},
    },
}

func (o exampleOption) main(c *cli.Context) error {
...
}

[ccremer]

I think I can come up with something like this 👍

[ccremer]

with json log format it looks like this:

go run ./... --log-format json -d example --flag "asdf"
{"level":"info","ts":1641483801.989945,"logger":"go-bootstrap","caller":"go-bootstrap/main.go:98","msg":"Starting up go-bootstrap","version":"unknown","date":"2022-01-06","commit":"-dirty-","go_os":"linux","go_arch":"amd64","go_version":"go1.17.5","uid":1000,"gid":1000}
{"level":"debug","ts":1641483801.989997,"logger":"go-bootstrap.example","caller":"go-bootstrap/example_command.go:31","msg":"validating config","version":"unknown"}
{"level":"info","ts":1641483801.9900086,"logger":"go-bootstrap.example","caller":"go-bootstrap/example_command.go:40","msg":"Hello from example command!","version":"unknown","config":{"ExampleFlag":"asdf"}}

[glrf]

LGTM! I really like how you handle configs now and this makes commands easy to test.

[bastjan]

Looks good overall 🚀 One question for my understanding...

[bastjan]

Looks good now 👍

The sample could include a a WaitGroup to make it more real life. Usually you have to wait for the shutdown.

[ccremer]

@bastjan Hopefully the last objections are now integrated :)
I feel pretty confident now

[bastjan]

Looks good to me now! 🎉 Thanks for the work 😊