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

A snap confined shell based on Mir: Mircade

Mircade: An example snap confined user shell There are various scenarios and reasons for packaging a Snap confined shell and a selection of applications together in a confined environment. You might have applications that work well together for a particular task; or, you may want to offer a number of alternative applications and have them […]

A blast from the past – Shutter

The wheel of software turns, and apps come and go. But the end of development does not always mean the end of usefulness. Sometimes, programs stubbornly remain around, offering a complete experience that can withstand the test of time. Several weeks ago, we talked about how you can preserve old applications with snaps. Today, we […]