A snap is a bundle of an app and its dependencies that works without modification across many different Linux distributions. They are app packages for desktop, cloud and IoT that are easy to install, secure, cross-platform and dependency-free. Snaps are discoverable and installable from the Snap Store, an app store with an audience of millions.
Types of snap
The snap packaging ecosystem consists of the following parts:
- snap is both the command line interface and the application package format
- snapd is the background service that manages and maintains your snaps
- snapcraft is the command and the framework used to build your own snaps
- Snap Store provides a place to upload your snaps, and for users to browse and install
Snapcraft is a powerful and easy to use command line tool for building snaps. It reads a simple, declarative file and runs the build for us. You can create snaps from apps you’ve already built and zipped, or from your preferred programming language or framework.
The following is an outline of the typical snap build process, which you can step through to create your snap:
- Create a checklist
Better understand your snap’s requirements.
- Create a snapcraft.yaml file
Describes your snap’s build dependencies and run-time requirements. It contains the metadata of the application.
- Add interfaces to your snap
Share system resources with your snap, and from one snap to another
- Publish and share
Put your snap on the Snap Store to reach an audience of millions
Difference between Snap and Apt:
Snap Vs. APT: Which One to Choose?
Choose Snap if:
- You do not want unnecessary packages to be integrated into your system. With Snaps, the packages remain confined in the
- You want to make sure you have the most up-to-date version of the app. Snap updates automatically and continuously, without feature freezes for specific distributions.
- You want to isolate an app.
Choose APT if:
- You prefer apps to be reviewed by the distribution you are using.
- You are concerned about conserving your storage space. Apps installed by APT share their dependencies.
- You want apps to integrate into the GUI environment properly.
Snaps update automatically, and by default, the snapd daemon checks for updates 4 times a day. Each update check is called a refresh.
Manually updating snaps
Regardless of when a refresh is scheduled, an update refresh can be initiated with the
snap refresh command:
The refresh command can also be used to see when the last refresh occurred and when the next is scheduled:
The first line in the above output shows the value of the timer system option. This defines how and when a refresh should be scheduled.
A snapshot is a copy of the user, system and configuration data stored by snapd for one or more snaps on your system. This data can be found in
snap save command creates a snapshot for all installed snaps, or if declared individually, specific snaps:
Now lets discuss snapcraft in detail. It is defined as the heart of snap ecosystem. It is a powerful and easy to use command line tool for building snaps. It helps you to:
- build and then publish your snaps on the Snap store
- use channels, tracks and branches to finely control updates and releases
- build and debug snaps within a confined environment
- update and iterate over new builds without rebuilding the environment
- test and share your snaps locally
Lets start by installing snapcarft, It can be done by using simple command:
sudo snap install snapcraft --classic
--classic argument is required because snapcraft uses classic confinement.
At the heart of the snapcraft build process is a file called snapcraft.yaml. This file describes a snap’s build dependencies and run-time requirements, it integrates remote repositories and extensions, and runs custom scripts and hooks for better integration with CI systems.
To get started, run
snapcraft init. This creates a buildable snapcraft.yaml template within a snap sub-directory relative to your current filesystem location.
The typical snap build process centres on iterating over the configuration of parts, plugins and interfaces within this snapcraft.yaml file:
- parts are the raw building blocks of a snap, used to collect and build binaries and their dependencies.
- plugins are used within parts to better integrate projects using languages and framework.
- interfaces enable resources from one snap to be shared with another, and with the host system.
The snapcraft format
The snapcraft.yaml file is the main entry point to create a snap through Snapcraft. It contains all the details the snapcraft command needs to build a snap.
In general, snapcraft.yaml can be organised into three principle sections:
1. top-level metadata, containing values, such as name, typically used by the store:
summary: GNU Hello, the "hello world" snap
GNU hello prints a friendly greeting.
Let’s go through this line by line:
- name: The name of the snap.
- base: A foundation snap that provides a run-time environment with a minimal set of libraries that are common to most applications. The template defaults to using
core18, which equates to Ubuntu 18.04 LTS.
- version: The current version of the snap. This is just a human readable string. All snap uploads will get an incremental snap revision, which is independent from this version. It’s separated so that you can upload multiple times the same snap for the same architecture with the same version. See it as a string that indicates to your user the current version, like “stable”, “2.0”, etc.
- summary: A short, one-line summary or tag-line for your snap.
- description: A longer description of the snap. It can span over multiple lines if prefixed with the ‘|’ character.
- grade: Can be used by the publisher to indicate the quality confidence in the build. The store will prevent publishing ‘devel’ grade builds to the ‘stable’ channel.
- confinement: A snap’s confinement level is the degree of isolation it has from your system, and there are three levels:
devmode. strict snaps run in complete isolation,
classicsnaps have open access to system resources and devmode snaps run as strict but with open access to the system. The latter is ideal for development, but your snap will need move from devmode to be published. See Snap confinement for more details.
2. apps detailing how apps and services are exposed to the host system:
3. and parts are used to describe your application, where its various components can be found, its build and run-time requirements, and those of its dependencies. A snap consists of one or more parts, depending on its complexity.
So we have added a part called
gnu-hello (its name is arbitrary). For ‘source’, we specified a tarball(a group of files collected together as one) located on the GNU project’s FTP server. As ‘plugin’ we’ve chosen
autotools which uses the traditional
./configure && make && make install build steps.
Building your snap
When you are ready to test the contents of snapcraft.yaml, simply run
snapcraft --debug in the same directory where you initialised the snap.
If this is the first time you’ve built a snap with snapcraft, you will either need to have Multipass(Multipass is the recommended method to create Ubuntu VMs on Ubuntu. It’s designed for developers who want a fresh Ubuntu environment with a single command and works on Linux, Windows and macOS) installed, or you will be prompted to install it before the build continues:
$ snapcraft --debug
Support for 'multipass' needs to be set up. Would you like to do it now? [y/N]: y
--debug argument isn’t necessary, but it helps hugely when testing a new snapcraft.yaml. With
--debug, if snapcraft encounters an error it will automatically open a shell within your snap’s virtual environment. You can then explore the build issue directly.
Testing your snap locally
After a snap has been built, it can be installed locally with the
--devmode flags, enabling your unsigned and unconfined snap to be installed:
$ sudo snap install hello_0.1_amd64.snap --dangerous --devmode
hello 0.1 installed
Lets build a simple ubuntu snap:
We will be building a simple DOSBox snap and will break it down step-wise:
Step1: Make sure you have snap installed by using:
See Installing snapd if snap isn’t installed.We can now install Snapcraft with a single command:
$ sudo snap install snapcraft --classic
Step2: Starting the project
The first thing to do is to create a general snaps directory followed by a working directory for this specific snap project:
$ mkdir -p ~/mysnaps/hello
$ cd ~/mysnaps/hello
It is from within this hello directory where we will invoke all subsequent commands.
Step3: Get started by initialising your snap environment:
$ snapcraft init
This creates a
snapcraft.yaml in which you declare how the snap is built and which properties it exposes to the user.
Step4: It’s now time to customise the snapcraft.yaml file for our own snap. Taking the above into account, we can change the top of the file to be:
summary: GNU Hello, the "hello world" snap
GNU hello prints a friendly greeting.
Step5: Parts define how to build your app. Parts can be anything: programs, libraries, or other assets needed to create and run your application.
Before building the part, the dependencies listed as
build-packages are installed. The autotools plugin uses the standard tools,
make to build the part.
Step6: Define your app part. Apps are the commands and services exposed to end users. If your command name matches the snap name, users will be able run the command directly.
Step7: After you’ve created the
snapcraft.yaml file, you can build the snap by simply executing the snapcraft command in the project directory:
Using 'snapcraft.yaml': Project assets will be searched for from the 'snap' directory.
Launching a VM.
Step8: The resulting snap can be installed locally. This requires the
--dangerous flag because the snap is not signed by the Snap Store. The
--devmode flag acknowledges that you are installing an unconfined application:
$ sudo snap install hello_2.10_amd64.snap --devmode --dangerous
Step9: You can then try it out:
Step10: Removing the snap is simple too:
$ sudo snap remove hello
Step11: You can clean up the build environment with the following command:
$ snapcraft clean
By default, when you make a change to snapcraft.yaml, snapcraft only builds the parts that have changed. Cleaning a build, however, forces your snap to be rebuilt in a clean environment and will take longer.