Implement custom go format for list command

[afbjorklund]

Closes #318

[jandubois]

I'm wondering what the use-case for this is. At first I expected the output to still have proper column format etc, but that is of course not possible when using generic go templates (maybe we should also have a --labels or --fields option where you can specify the columns that you want).

I think for this particular PR the --template name would be more appropriate (but yes, I realize docker uses --format as well, but e.g. kubectl doesn't).

To be useful there needs to be a way to list all available template variables, either as part of limactl ls --help, or via a separate command. That information should then be reusable for the --labels or --fields options.

One use case I could think off was creating an ssh command to connect to the instance using the template. But that requires that you can limit the limactl ls output to a single instance, so maybe that needs to be supported as well.

Anyways, I would still like to understand how this feature is expected to be used.

[afbjorklund]

There were similar functions for podman machine list (or even docker version)

The alternative was doing something like --json | jq, to extract a couple of fields ?

[afbjorklund]

One use case I could think off was creating an ssh command to connect to the instance using the template. But that requires that you can limit the limactl ls output to a single instance, so maybe that needs to be supported as well.

You can do that with "grep" now, but yes that would be nice too.

[afbjorklund]

At first I expected the output to still have proper column format etc, but that is of course not possible when using generic go templates

I think Podman made up some home-grown table function for this, they showed on the last community meeting...

$ podman machine ls --format 'table {{ .Name }} {{.Default}}'
NAME                     DEFAULT
podman-machine-default*  true

[jandubois]

I think Podman made up some home-grown table function for this, they showed on the last community meeting...

$ podman machine ls --format 'table {{ .Name }} {{.Default}}'
NAME                     DEFAULT
podman-machine-default*  true

Ok, thats fine. I thought for kubectl you could just provide a comma separated list of field names, but it is more complex (but also more expressive):

$ kubectl get pods -A -o custom-columns='NAME:.metadata.name,IMAGES:spec.containers[*].image'
NAME                                     IMAGES
helm-install-traefik-8569p               rancher/klipper-helm:v0.3.0
svclb-traefik-tmz9l                      rancher/klipper-lb:v0.1.2,rancher/klipper-lb:v0.1.2
traefik-5dd496474-87cbj                  rancher/library-traefik:1.7.19
coredns-66c464876b-xrcbn                 rancher/coredns-coredns:1.6.9
local-path-provisioner-7ff9579c6-8tnvq   rancher/local-path-provisioner:v0.0.14
metrics-server-7b4f8b595-whrjs           rancher/metrics-server:v0.3.6
builder-4fl6p                            docker.io/moby/buildkit:v0.8.3,rancher/kim:v0.1.0-beta.6

[AkihiroSuda]

The 'table {{ .Name }} {{.Default}}' format looks good.

NAME:.metadata.name,IMAGES:spec.containers[*].image looks too complex

[jandubois]

NAME:.metadata.name,IMAGES:spec.containers[*].image looks too complex

It does. I thought you could write: kubectl get pods -A -L NAME,STATUS, but it looks like I misremembered.

I don't understand how the table thing works. It kind of looks like a template, but also not really: How can you tell that you don't want it to produce:

table podman-machine-default*  true

Anyways, extending the tabular output seems independent of the goal of this PR, so should be out of scope. Sorry for hi-jacking the discussion.

[afbjorklund]

minikube has some weird "fences" between columns

|---------|-----------|---------|--------------|------|---------|---------|-------|
| Profile | VM Driver | Runtime |      IP      | Port | Version | Status  | Nodes |
|---------|-----------|---------|--------------|------|---------|---------|-------|

In the old days, we just used tabs or something and then piped into a post processor

[jandubois]

Sorry for derailing the PR with the extended discussion. What I would like to see for this PR is that limactl ls --help will document which fields are available in the template. With that I'm fine with merging it.

I would also like to see limactl ls accept the name of one or more instances, and only list data for those instances, but that can be a separate PR.

As for #322 I would prefer to not add global constants into the Instance struct but merge them into the template data like this:

@@ -74,7 +77,16 @@ func listAction(cmd *cobra.Command, args []string) error {
                                logrus.WithError(err).Errorf("instance %q does not exist?", instName)
                                continue
                        }
-                       err = tmpl.Execute(cmd.OutOrStdout(), inst)
+                       var data struct {
+                               store.Instance
+                               LimaHome string
+                               IdentityFile string
+                       }
+                       configDir, _ := dirnames.LimaConfigDir()
+                       data.Instance = *inst
+                       data.LimaHome, _ = dirnames.LimaDir()
+                       data.IdentityFile = filepath.Join(configDir, filenames.UserPrivateKey)
+                       err = tmpl.Execute(cmd.OutOrStdout(), data)
                        if err != nil {
                                return err
                        }

This provides the desired functionality without duplicating the global data into each instance struct:

$ l ls --format '{{.Name}} {{.LimaHome}} {{.IdentityFile}}'
aarch64 /Users/jan/.lima /Users/jan/.lima/_config/user
alpine /Users/jan/.lima /Users/jan/.lima/_config/user
colima /Users/jan/.lima /Users/jan/.lima/_config/user
default /Users/jan/.lima /Users/jan/.lima/_config/user

This can be included in this PR, or could be a separate one as well.

[jandubois]

Here is the halog function I wrote about in #322 (without using the ill-thought-through --exec option):

$ function halog { tail -f "$(limactl ls -f ""{{.LimaHome}}/{{.Name}}/ha.stderr.log"" | grep ${1:-default})"; }
$ halog
[...]
{"level":"info","msg":"Sending QMP system_powerdown command","time":"2021-10-12T20:31:45-07:00"}
{"error":null,"level":"info","msg":"QEMU has exited","time":"2021-10-12T20:31:46-07:00"}
^C
$ halog alpine
[...]
{"level":"info","msg":"Not forwarding TCP [::]:22","time":"2021-10-07T19:11:48-07:00"}
{"level":"info","msg":"Not forwarding TCP 0.0.0.0:22","time":"2021-10-07T19:11:48-07:00"}
^C

Still would be better if the grep could be replaced by passing the instance name directly.

PS: I realize this function is interesting only when you use different shells with different LIMA_HOME settings simultaneously.

[jandubois]

LGTM, although I have a slight preference to have --list-fields return them in sorted order. Maybe you can still update?

Not going to merge in case @AkihiroSuda has further feedback.

[AkihiroSuda]

Thanks