Introduce formatter and output mechanism

[krisnova]

We need a clean way to output and query the output of the program.

Ideally we will be able to do something like the following:

ae get pods --json # Spits out something we can pipe to jq
ae get pods --yamo # Spits out something we can pipe to yq
ae get pods --go # Spits out syntactically correct Go structs we can copy/paste
ae get pods --table # Spits out a table in stdout that is auto formatted to the terminal

[krisnova]

Note: we do not want a logger like Logrus as we want to be able to query the data that ae returns natively on the command line

[keltia]

As told on stream, github.com/intel/tfortools is a great table formatter. (@Corwyn666)

[daegalus]

For pretty outputs over interop outputs, I recommend Charm libs. https://charm.sh/ specifically Bubble Tea and Lip Gloss

[RRethy]

I've started looking at this, I should have time on the weekend to put my changes in a PR.

[voigt]

Thought about this one a bit now and have a couple of thoughts I'd like to share/discuss:

• Where is --go as a requirement coming from? I don't quite understand what scenarios this might be useful. Is it worth the effort? Any examples of apps that have this?
• What exactly do we mean by "table"? Like a list of tabbed values or do we insist on decorators like borders etc.?
• Are there additional requirements to a table output like kubectls --format option?
• Can we guarantee 2D objects that we want to print?

I was looking into the implementation of kubectl, which seems to use https://github.com/liggitt/tabwriter. I guess we could reuse quite a bit of its implementation if we'd follow a similar approach: link.

• Skimming this code I thought about another output format that I like using kubectl: -o jsonath='{...}' - may be another thing we would like to support?

@keltia mentioned github.com/intel/tfortools, which sounds like a nice option, but is already archived. Not sure if we should rely on it, as it is not maintained anymore.

[RRethy]

Where is --go as a requirement coming from? I don't quite understand what scenarios this might be useful. Is it worth the effort? Any examples of apps that have this?

I'm curious about this too. Would it print a struct definition, a instance of a struct, or client-go grpc code to use the struct? I can say it would've been cool (and useful) if kubectl would print out valid client-go code based on the get command I ran so I'd open to trying that out (after we get our grpc client merged).

What exactly do we mean by "table"? Like a list of tabbed values or do we insist on decorators like borders etc.?

I was thinking something like kubectl -owide.

Can we guarantee 2D objects that we want to print?

I wouldn't think so, I'd expect it to depend on the subcommand. That's one of the reasons in my PR above the printers are configured by the subcommand.

@keltia mentioned github.com/intel/tfortools, which sounds like a nice option, but is already archived. Not sure if we should rely on it, as it is not maintained anymore.

I looked at that too, I agree with what you said about jsonpath as an alternative, or we could also just rely on -o json and let users pipe the output into jq.