“All my centurions develop using snaps.”Julius Caesar
By and large, software development can be an enjoyable process. Until you hit the first error, that is. At that point, you want to get past the stumbling blocks as quickly as possible and resume building your apps. A robust, flexible development framework can make a big difference in how fast you can resolve the issues. Furthermore, good familiarity with how development tools behave can significantly improve the pace at which you iterate.
Snapcraft offers several useful features and options that enable you to speed up your work making snaps. Whether you’re a newbie or a veteran of many a snap, we’d like to show you some practical tips and tricks that ought to make your snap development experience even more streamlined – and snappier.
Snapcraft 3.0 introduced a new functionality called bases, which somewhat changed how snapcraft builds applications.
A base is a special kind of snap that provides a minimal set of libraries common to most applications. A base snap mounts itself as the root filesystem within your snap. Then, at runtime, the base’s library paths are searched directly after the paths for your specific snap.
Bases are defined by adding the base: keyword to your snapcraft.yaml, followed by the base name. With bases, you can leverage newer libraries and build toolchain from relevant archives (like Ubuntu, Fedora, etc). For instance, to specify Core 18, a snap based on the Ubuntu 18.04 LTS and the current standard base for snap building, you would add the following:
Another important addition is the use of Multipass, a system that orchestrates the creation, management and maintenance of virtual machines for simplified development. Prior to version 3.0, snapcraft used the LXD container management tool to create build instances.
For people starting fresh in the snap world, these changes are largely transparent. However, if you have previously packaged snaps using LXD and have not used bases, you may have some initial transition issues, and it is good to know how to handle the new development environment in a seamless manner.
If you’re lucky (or exceptionally talented), you will have written your snapcraft.yaml perfectly on the first go, and the snap will build without any errors. But this may not always be possible. Typically, your build process will consist of trial and error – you will make a change to snapcraft.yaml, run snapcraft, wait for the build to finish, and then repeat if needed. In some cases, you may also want to start ‘fresh’, in which case, you will run:
Without additional arguments, this will delete the virtual machine and all its contents, including the minimal operating system, the build setup, downloaded sources, and any built parts – it will not delete the snap or the source of your project. In some cases, rebuilding everything from scratch can be a bandwidth- and time-consuming process, and you will most likely want to iterate faster.
It is possible to run snapcraft with the debug option (–debug), which will open a shell in the virtual machine if the build process fails, allowing you to inspect any issues and make changes. For instance:
Launching a VM.
snapcraft 3.2+git2.g9e83f45 from Canonical installed
The ruby plugin is currently in beta, its API may break. Use at your own risk
Skipping pull mdl (already ran)
Cleaning later steps and re-building mdl ('build-packages' property changed)
/bin/sh: 29: rake: not found
Failed to run 'override-build': Exit code was 127.
You will now see an open shell in front of you, e.g.:
This is the actual snap build environment shell within the virtual machine (named snapcraft-”your-snap-name”), and you can inspect its contents, make any changes, and then re-run snapcraft. Now, this is where the time-saving element comes in. You can make changes to snapcraft.yaml outside the build environment shell (in your home directory or wherever your project snapcraft.yaml is located) and then run snapcraft inside the virtual machine. You do not need to make manual changes inside the virtual environment. We will explain how this works in a moment.
Inside the Multipass VM instance, in the /root directory, you will see the following directory structure:
Now that we understand what happens in the background, and what a typical Multipass VM instance contains, we can now speed up the development. You can open a shell, manually manipulate or tweak any components (like sources or libraries), make changes to the snapcraft.yaml file, and then run again.
Now, it is possible you may encounter the exact same errors as before, even though you have changed your snapcraft.yaml. In this case, you will need to clean the parts already built, and since you’re inside the VM, you can do it yourself, like:
snapcraft clean ”part name”
Then, when you re-run snapcraft, the part will be built again, using the new YAML declaration.
If the build is successful, you will have the .snap file, and you won’t need to do any manual changes. The snap will be located in your project directory, which is mapped to your home directory (or work environment). You can just exit the VM shell at this stage.
If you require LXD containers (for instance, in a scenario where it is not possible to use nested virtual machines created by Multipass), you can still create them with snapcraft 3.0, so you can test changes to your snaps and gradually adapt your snapcraft.yaml to use bases.
For most non-base use cases, running snapcraft cleanbuild is the simplest (and often faster) option. This command will spawn a brand new container instance, setup the minimal OS inside it, and download all the necessary packages to build a snap. If you encounter errors, the documentation outlines some advanced options on how to setup and run containers yourself.
There are still a few other things you can do to make your snapping faster and easier:
Snapcraft is designed to be flexible and cater to a wide range of users. That also means that some of the “advanced” features are not instantly visible, but they do offer useful functionality that can enhance and simplify development.
In this article, we touched on the concept of bases, the use of Multipass and LXD tools, debug options, the content of build systems, and expanded on general suggestions that can make your development with snapcraft smoother, faster and ultimately, more enjoyable. If you have any comments or suggestions, please join our forum for a hearty discussion.
No containers or centurions were harmed in the production of this article.
Learn how the Ubuntu desktop operating system powers millions of PCs and laptops around the world.
Using acpidbg on Ubuntu 18.04 x64 can be quite handy; however, the Linux kernel with ACPI_DEBUGGER is not always available, such as on Ubuntu for ARM. In such cases, acpica also provides a set of utilities, named acpica-tools, for ACPI…
At Canonical, helping customers overcome their challenges is what we do every day. In the IoT world, a common challenge we encounter is customers who are interested in transitioning to Ubuntu Core and the snapcraft.io ecosystem, but are…
During February 2019 we celebrated another fine Plasma release with our friends at KDE by showcasing a month of KDE snaps on the Snapcraft Twitter and other social accounts. The KDE developers have done amazing work to create an SDK that…