Add --yq option to limactl list and limactl info

[jandubois]

The --yq option is only compatible with JSON or YAML output and will apply the yq expression to the result before writing it to the output.

The following 2 commands are functionally identical (but may result in different formatting, see below):

limactl ls default --yq .dir
limactl ls default --format json | limactl yq .dir

The output of limactl list --json will be pretty-printed when it goes to a terminal. This means it is no longer one line per JSON object, but has much improved legibility. Output to a file or pipe maintains JSON Lines rules.

Also colorize the output of limactl list, limactl info, limactl tmpl copy, and limactl tmpl yq if the output goes to the terminal.

Unfortunately the output of yamlfmt cannot be colorized, so the terminal output may look slightly different from the output to a file or pipe (mostly the extra indentation of list elements), but this seems like a reasonable compromise.

Sample screenshot to show the difference:

The colors come from https://github.com/mikefarah/yq/blob/master/pkg/yqlib/color_print.go and are not configurable.

[AkihiroSuda]

Why not use limactl list --format '{{.Dir}}' ?

[jandubois]

Why not use limactl list --format '{{.Dir}}' ?

❯ l ls default --format '{{.Config.User}}'
{0x14000a033e0 0x14000a033f0 0x14000a034d0 0x14000a03410 0x1400092fdd8}

❯ l ls default --yq .config.user
{
    "name": "jan",
    "comment": "Jan Dubois",
    "home": "/home/jan.linux",
    "shell": "/bin/bash",
    "uid": 501
}

[jandubois]

And to elaborate on this a bit more, limactl ls --list-fields tells you about the Config field (without further explanation), but limactl ls default --format '{{.Config}} doesn't help you to figure out the structure underneath it.

You have to know to look into https://github.com/lima-vm/lima/blob/master/pkg/limatype/lima_yaml.go to find out the Go internal structure.

With --yq you just use the structure that is returned by limactl ls default --format json and take it from there. Everything is easily discoverable. For a non-Lima developer, the .Config value is totally opaque.

I would consider the Go template format a legacy option that we added because we didn't have anything better yet.

[AkihiroSuda]

❯ l ls default --format '{{.Config.User}}'
{0x14000a033e0 0x14000a033f0 0x14000a034d0 0x14000a03410 0x1400092fdd8}

--format '{{json .Config.User}}' should work

[jandubois]

--format '{{json .Config.User}}' should work

It does, but it is still obscure. How do you know the struct field is called .User?

It makes much more sense for the user to be able to use the same field name that is used in lima.yaml.

Why do they have to check the Lima source code to figure out how to write the template expression?

[jandubois]

Using --yq is also about more than simply selecting a field from the structure. You can use it to filter the list of your instances according to whatever criteria you want (see #3240, which we probably should remove from the 2.0 milestone).

❯ l ls --yq 'select(.config.vmType == "vz").name'
bar
clone
default

❯ l ls --yq 'select(.config.vmType == "qemu").name'
qemu

❯ l ls --yq 'select(.status == "Running").name'
default
qemu

[AkihiroSuda]

Thanks

[AkihiroSuda]

Probably we should have bats tests

[jandubois]

Probably we should have bats tests

They will come. I've been working on BATS tests; that how I found some of the issues with limactl ls, like the JSON and YAML data being different.