Announcing snapcraft 2.35

by Sergio Schvezov on 22 November 2017

The snapcraft team is pleased to announce that version 2.35 has been released.


This release saw some excellent contributions from outside the snapcraft core team, and we want to give a shout out to those folks. A team thank you to:

New in this release



Each build instance created now correctly works out isolated temporary folder locations for those users running many builds in parallel. There is also better detection of existing or missing lxd installations so first time users can better understand any problems with the host they are currently trying to use.

When running snapcraft from the snap, snapcraft now injects itself into the actual snap instead of apt installing the deb (for the case of today of only supporting one base), providing parity with the local environment at hand.

Work has been added to get rid of all the corner cases and provide useful feedback to users and making the experience feel more native.
Additionally, support has been added for using remote lxd instances.

To enable the persistent build containers feature the SNAPCRAFT_CONTAINER_BUILDS environment variable needs to be set.

Here’s an example of using a remote lxd instance:



On this new version we added more information to the build manifest, like the contents of lock files, the debs and snaps installed in the machine, information from uname and the fingerprint of the container used for the build. To record the build manifest, set the environment variable SNAPCRAFT_BUILD_INFO. The manifest will be saved and distributed inside the snap. After the build, you can inspect it in the prime/snap/manifest.yaml.


Command Line Interface

new command: pack

This new pack command replaces the now deprecated use of snap <snap-dir> with the goal of decoupling the concept of working on an actual snapcraft project and packing up a directory layout into a snap.

new command: refresh

This command is only available when persistent build containers are enabled and exists to make the environment feel as native as possible. Prior to the existence of this command, building continuously in a container triggered a refresh of the packaging archive every time, now this refresh only takes place on container creation or when called through snapcraft refresh.

new command: edit-collaborators

This command will eventually replace the use of the store invites mechanism to setup other people as collaborators to the project. It is currently hidden as the production snap store has it currently disabled. A future release once things have stabilized will expose the command to users. It is harmless to use today as a proper error will show up.

In the meantime, here is how it works when using the integration store:

OS Support


Initial support for running the snapcraft snap on solus has been added. It should work well enough for things like performing store operations, packing up snaps; or if lxd is installed and setup, most operations should work through use of persistent build containers or cleanbuild.

We look forward to knowing how this initial experience performs.

Ubuntu 14.04

Snapcraft currently only really runs well on Ubuntu 16.04, but we’re working on adding support for other releases and Linux distributions. This is the first release where you can use the Snapcraft snap on Ubuntu 14.04 (Trusty). This is particularly important for snaps based on ROS (Robot Operating System) Indigo, which targets Trusty. Here’s a demo of just that:




This plugin developed by Rajesh, a .NET developer at Microsoft, allows you to create .NET 2.x based snaps, currently embedding the runtime with plans to enhance it to understand content snaps of .NET runtimes which could be leveraged by projects.

The syntax is pretty straightforward and builds on language understood by upstream so getting started for a current .NET developer should feel like a pleasant journey.

Here is the plugin in action:


This release sees the addition of a Ruby plugin, written by James Beedy. It supports a number of different Ruby versions by building them from source, which takes a little while but makes it pretty versatile. It could definitely use some exercise! Here’s an example of building a snap of the Travis gem:



The Catkin plugin has long supported rosdep to resolve and fetch system dependencies (i.e. Debian packages). However, rosdep also supports resolving pip dependencies. This release adds support for those, so they don’t need to specified elsewhere in the snapcraft.yaml.

Final notes

To get the source for this release, check it out on github.

A great place to collaborate and discuss features, bugs and ideas on snapcraft are the forums. Please also feel free to file a bug.

Happy snapcrafting!
— Sergio and the team

Newsletter Signup

Related posts

Fabrica – Your self-hosted snap factory

There are many ways one can go about building snaps. You can do it on your local system, by manually running commands in a terminal window. If you have a developer account in the Snap Store, you can use the integrated build functionality to create snaps. You can also use Launchpad, Electron Builder or a […]

Snapcraft development tips: how to troubleshoot snaps with services

In the past, we have discussed various ways on how to debug and troubleshoot potential issues during snap development. The ability to quickly iterate, resolve build process hurdles and publish the application in a timely manner is essential to a robust, positive development experience. Today, we would like to outline a few basic tips and […]

Experimental feature: progressive releases

“No plan survives contact with the enemy.” This is a quote famously attributed to the Prussian field marshal Helmuth von Moltke. It is also quite applicable to software development: “No code survives contact with the user.” In mission-critical environments, staggered deployments of software are a crucial part of controlled updates, design […]