Development tips and tricks – snap try and snapcraft pack

by Igor Ljubuncic on 27 June 2019

Over the past several months, we have shared with you several articles and tutorials showing how to accelerate application development so that a typically demanding, time-consuming process becomes an easier, faster and more fun one. Today, we’d like to introduce some additional tips and tricks. Namely, we want to talk about elegant ways you can streamline the final steps of a snap build.

Snap try

A rather handy thing you can do to speed up the development and testing is the snap try command. It allows you to install a snap AND make live (non-metadata) changes to the snap contents without having to go through the build process. This may sound a little confusing, so let’s discuss a practical example.

Say you built a snap, and you want to test how it works. Typically, the standard process is to install the snap (with the –dangerous flag), and then run the snap. Early in the testing process, a likely scenario is that a snap may not launch because it could be missing runtime libraries. With the usual development model, you would iterate in the following manner:

  • Edit the snapcraft.yaml.
  • Add relevant stage packages to include necessary runtime libraries.
  • Re-run the build process.
  • Remove the installed snap.
  • Install the new version and test again.

This is perfectly fine, but it can take some time. The alternative approach with snap try allows you to make live changes to your snap without going through the rebuild process. The way snap try works, it installs the snap, and it uses the specified directory (containing the valid snap contents) as its root. If you make non-metadata changes there, they will be automatically reflected. For instance, you can add libraries into usr/lib or lib, and see whether you can resolve runtime issues during the test phase. Once you’re satisfied the snap works well, you can then make the one final build.

Where do you start?

The easiest way is to simply unsquash a built snap, make changes to the contents contained inside the extracted squashfs-root directory, and then snap try against it, and see whether you have a successful build with all the assets correctly included. Moreover, with snap try, you can also change confinement modes, which gives you additional flexibility in testing your snap under different conditions, and see whether the application works correctly.

snap try
electron-quick-start 1.0.0 mounted from /home/igor/snap-tests/electron-quick-start/dist/squashfs-root

Snapcraft pack

Side by side with snap try, you can use the snapcraft pack command. It lets you create a snap from a directory holding a valid snap (the layout of the target directory must contain a meta/snap.yaml file). Going back to our previous example, you would alter the contents of your project directory, add assets (like libraries), and then pack those into a squashfs file.

snapcraft pack .
Snapping 'electron-quick-start' /
Snapped electron-quick-start_1.0.0_amd64.snap

The two commands, snap try and snapcraft pack, complement each other really well. For instance, while you cannot make live changes to metadata for snap try without reinstalling the snap (directory), you can edit the snap.yaml file and pack additional snaps, allowing you to quickly test new changes.

You can also manually create your own snap and pack them for both offline and online distribution. This might be useful if your application language isn’t currently supported as a plugin in snapcraft, or if you have ready archives of binary code you want to assemble into snaps in a quick and convenient way.


Sometimes, small things can make a big difference. The ability to quickly make changes to your snaps in the testing phase, while still retaining the full separation and containment from the underlying system provides developers with the peace of mind they need to iterate quickly and release their applications. Snap try and snapcraft pack are convenient ways to blend the standard build process and runtime usage in a streamlined manner. As always, if you have any comments or suggestions, please join our forum for a discussion.

Photo by chuttersnap on Unsplash.

Newsletter Signup

Related posts

The Future of Snapcraft

System hysteresis, when applied to software, can roughly be defined as an overall lag between desired implementation of code and actual implementation of said code. Ideally, this delay should be minimal, and programmers would be able to make instantaneous changes and improvements to their applications. In reality, things are more complex […]

Ubuntu Frame – A picture is worth a thousand snaps

The development of graphical applications intended for use on IoT devices isn’t trivial. The complexity goes beyond the usual challenges that exist in the classic desktop and server domains. One, the IoT world is much less mature. Two, developers need to take into consideration various edge cases that do not apply to hands-on devices like […]

Craft Parts – Reusable code, Snapcraft style

Throughout the ages, humans have always used simpler tools and materials to create more complex ones. Wood and stone for smelting bronze and iron; iron to create steel; vacuum tubes to create logical gates; logical gates to create advanced arithmetic engines, and so on. Modern software is no different. With Snapcraft in particular, the sn […]