Well, one could have VM generator functions, so that you can easily generate a development-like VM or a reasonable-setup like VM or minimal VM (without D-Bus etc.), and so the developers can just use the dev version and always get the good stuff included?
Yes, that's true.
Just as a quick refresher, currently if you want to make a Spectrum VM, these are your options:
- Lay out the VM configuration directory manually in the user data partition, and bring your own kernel/rootfs.
- As above, but use the rootfs and kernel in /usr/img/appvm. These aim to provide a "standard" environment that can be shared between application VMs, so it comes with mesa, and in future virtio-gpu set up, as well as D-Bus, PipeWire, etc. It mounts a second block device that contains your application, as well as any dependencies not included in the base image, and then runs your application from there. This way, big stuff like mesa only has to exist once on disk.
- Create an application VM that uses /usr/img/appvm with Nix, using vm-lib/make-vm.nix.
Yes, sorry, I have still not tried all this (I am going to avoid Wayland as the main UI as long as practical, and I am not going to commit enough time to Spectrum-adjacent things to make it worth your time to ask how would I set up things for Spectrum-like isolation of single things into Weston-inside-Xorg or whatever on host).
So what we're missing is a way to create, with Nix, a VM that isn't based on the /usr/img/appvm "template". The reason we don't currently have such a function is that I don't think it's clear yet how it should work — what should be customisable, what should be part of the base image vs. not, etc.? For a while, how make-vm.nix should work was similarly unclear, which is why it only recently came into existence. After I'd manually created my third or so application VM, it became clear what could be part of the base image, and what had to be customisable. Currently, we only have one VM in the tree that doesn't use the /usr/img/appvm template, netvm. Once we have more, I think it'll be easier to evaluate how a more minimal VM builder function should work.
Hm, I would say that I have a good experience solving such a problem with a Nixpkgs-overlay-like structure, i.e. a makeExtensible with all possible tunables defined as attributes, and then more complex data structures built out of them, as well as packages for the things.