Add yq subcommands to limactl and lima-guestagent

[jandubois]

Adding it to lime-guestagent allows us to use yq in provisioning scripts without having to install it from a package repository or downloading it from GitHub.

Adding it to limactl makes it available to integration tests without having to install it. It is essentially free because we already use yqlib inside limactl anyways, so the executable size doesn't really change.

The size of the (compressed) guestagent for aarch64 increases from 12MB to 14MB, which seems acceptable.

These are "hidden" commands that don't show up in --help output.

❯ limactl yq --version
yq (https://github.com/mikefarah/yq/) version v4.47.1

❯ limactl yq -n '.foo="bar"'
foo: bar

❯ lima lima-guestagent yq -n '.foo="bar"'
foo: bar

This PR is meant to support the "yq provisioning mode" proposed in #3892, but I think is also valuable on its own.

---

I was initially thinking about making this a busybox-style "multi-call" binary, so you could put a symlink called yq into /usr/local/bin and have it work as a regular yq binary. But I'm worried about shadowing a yq version installed by the user with a package manager, so didn't add this functionality.

[jandubois]

We probably should include a comment that the yq command implementation is copied from the upstream repo, and maybe also include the license file in our repo.

[jandubois]

I've modified the code to turn this into a proper multi-call binary:

❯ limactl --version
limactl version 1.2.0-204-gcfa73e3e.m

❯ limactl yq -n '.foo="bar"'
foo: bar

❯ ln -s $(which limactl) yq

❯ ./yq --version
yq (https://github.com/mikefarah/yq/) version v4.47.1

❯ ./yq -n '.foo="bar"'
foo: bar

[jandubois]

I've added a second commit to add a yq.lima symlink both on the host and inside the VM (assuming the guestagent install directory is on the PATH; at least for provisioning scripts I've added it explicitly).

❯ lima yq.lima --version
yq (https://github.com/mikefarah/yq/) version v4.47.1

I thought this fits in with our other docker.lima, kubectl.lima custom versions.

I've kept it in a separate commit, in case we decide we don't want to do this. I can squash if we want to keep.

I also have not tested the Windows command that copies the file instead of making a symlink.

[jandubois]

I'm kind of torn about installing yq.lima on Windows. I want to do it for consistency, but it feels wasteful to store a copy of limactl just because you don't have symlinks when you can also just use limactl yq instead of yq.lima.

I think I prefer to not install it on Windows; what do you think?

[AkihiroSuda]

yq.lima

This is confusing. The convention of <SOMETHING>.lima is to run <SOMETHING> inside an instance of Lima.

[jandubois]

I think I prefer to not install it on Windows; what do you think?

An alternative is to just create a symlink on Windows too, and ignore the failure if the user doesn't have "Developer Mode" enabled on their system (to allow non-admins to create symlinks).

[jandubois]

The convention of <SOMETHING>.lima is to run <SOMETHING> inside an instance of Lima.

Not really. It is a variant of the tool installed by Lima, that will automatically work with the daemons inside a Lima instance. But the tools run locally, as long as they are installed, and only fall back to running inside the VM when they don't exist locally.

The only tools that always run inside the VM are apptainer.lima and nerdctl.lima. All of docker.lima, kubectl.lima, and podman.lima run on the host.

The goal is to make the difference invisible. The .lima suffix is used to avoid shadowing the native tool.

[afbjorklund]

An alternative is to just create a symlink on Windows too

Couldn't you use a shell wrapper on Windows, and call limactl yq?

All of docker.lima, kubectl.lima, and podman.lima run on the host.

The main difference is that they just call the external tool, like yq here

[AkihiroSuda]

I still don't think we should expose this dev tool to end users in the same way as other *.lima helpers

[jandubois]

I still don't think we should expose this dev tool to end users in the same way as other *.lima helpers

I don't know, I thought it was useful, and think it fits the scheme of adding useful utilities with a .lima suffix. Especially lima-hostagent yq is a bit of a mouthful, but then it will probably be hidden by the provision.mode: yq feature anyways.

But whatever, I don't care that much, and have removed the extra commit. I only kept the change that yq.lima.exe would invoke yq, if the user makes the symlink themselves.

[AkihiroSuda]

Thanks