I’ve forked the LXD plugin and spent a couple of hours fixing it up.
There is no published, signed release yet, but if you build from source and copy packer-plugin-incus into the directory where you invoke packer, you can start fooling around.
The LXD plugin shelled out to lxc, and a find/replace in the codebase was enough to get simple re-packaging of an ubuntu container image working. However, I think long-term it’s better to use the Go SDK directly.
Packer + LXD historically has yielded fairly large images, and I’m interested in ways to mitigate that, at least a little, with post-processing, or clever build techniques. There is also the notion of supporting multiple build techniques (“builder types”), which is something the Azure packer plugin does. See the docs here: Azure | Integrations | Packer | HashiCorp Developer
The Azure plugin has a standard launch->run scripts->snapshot whole disk builder, but it also supports a rather interesting “chroot” builder, which relies on a pre-existing VM in your infrastructure, mounts a new disk on it, and provisions a rootfs in a chroot. The chroot builder can be radically faster, since there is no boot stage.
So perhaps there is an approach that we could explore for Incus builder types that are a middle ground between the current snapshot approach and distrobuilder. And if it could share code with distrobuilder, that would be even more awesome.