> > While I don't disagree with the suggestions here, if I may suggest a > workaround: > > If you find yourself using cleanbuild a lot (it makes a new ephemeral > container, builds, then destroys the container), you might find some > workflow improvements by simply developing the snap in a container. You > can even bind-mount the source from the host, if you want. This is the > workflow I use personally. It allows for one to fully customize the apt > sources while also utilizing Snapcraft's built-in stage package cache*, > and it doesn't clutter the development environment on the host.
Thanks Kyle! While this works, I don’t think it meets the pragmatic needs of the developer. It’s already complex enough to learn a new tool chain and figure out an effective edit/debug/test cycle. If I have to set up my own container for this, I end up adding yet more variables and possible sources of errors. We really need the tool to take care of this, otherwise everyone goes through the same pain (and mistakes) over and over. The big bottleneck here is the endless re-downloading of all the packages. If snapcraft could take care of this transparently and use a cache, things would proceed at a tolerable pace, without everyone having to re-invent their own wheel. Cheers, Michi. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
