@townsend As I see it, this causes a regression for package maintainers. With the previous approach it was very convenient to keep a “prime” directory, possibly mounted into a build container, that could be mounted as a snap through “snap try”, and work iteratively in it until all necessary adjustments were made and integrated into snapcraft.yaml. Now with multipass, builds are slow, there is no possibility to just hack and try some stuff in a half-working snap to work it out, and it generally goes backwards in terms of user friendliness.
Two comments re the Mac concern. If that’s really the motivation, couldn’t the same build environment be provided as a container for Linux systems and as a VM image on Mac? For snapcraft maintainers, doesn’t it ultimately come down to maintaining a tarball that can be extracted either in a container or on a virtual disk?
And second, I don’t know if I’m the only one who thinks this, but is it fair and reasonable to annoy Linux developers in order to facilitate support of a proprietary, closed source platform that many Linux users frankly don’t give a flick about, to put it mildly?