It uses the Docker CLI to build container images out of the Nix shells it creates, if you ask it to export one to a Docker image for you. Otherwise it just uses Nix locally, no virtualization.
I wonder if it takes this approach because there's some issue with using Nixpkgs' dockerTools on macOS— those tools let you create Docker/OCI images without even having Docker installed.
Can cross builds hit the main binary caches or is that awaiting Hydra support for content-addressed derivations? Are there big caches for cross-compiled packages?
1. Yes it is— there are many kinds of virtualization other than machine virtualization. Containers are a form of operating system virtualization.
2. Docker on non-Linux also requires machine virtualization; the `docker` CLI connects to a `dockerd` daemon running on a virtual machine.
The question I posed earlier is motivated by understanding this and knowing that on macOS, the binaries that devbox runs on your local machine are completely different (of a different architecture, even) than the binaries that devbox will pack into a Docker image. Since it uses Nix to build them, it either needs to run Nix in a virtual Linux guest (which it does using the guest that Docker for Mac sets up) or have its Mac-bound Nix build Linux binaries.
Using `docker buildx` obviates the need to set up devbox's own Linux VM to target as a remote builder, or, alternatively, cross compile the required Nix packages. But it comes at the cost of adding a dependency on Docker even though devbox doesn't use the Docker runtime for its shells
I wonder if it takes this approach because there's some issue with using Nixpkgs' dockerTools on macOS— those tools let you create Docker/OCI images without even having Docker installed.