Commands, daemons & assets

The entire syntax of a snapcraft.yaml with all available keys can be reviewed in the snapcraft.yaml syntax section. Here we will discuss the apps metadata in more detail.

Defining app commands

For every app you build in your snap, you can define which commands or daemons are shipped. Declaring them in snapcraft.yaml will expose them in the system. Starting with the apps keyword you specify each app and its functionality. So, if there were two apps, one called app1 and another called app2, the extract would look like

apps:
  app1:
    command: bin/app1
  app2:
    command: opt/bin/app2
    plugs:
      - network

So in the example, app1 will declare its command to the relative path bin/app1, while app2 defines a different command being opt/bin/app2 and using the network interface.

The Snapcraft wrapper script explained

It’s customary to use within your app small wrappers that will launch the real binaries. For instance, to select the binaries for the correct architecture or to set runtime variables such as the application state directory.

The typical wrapper is a small shell script that sets PATH, LD_LIBRARY_PATH or other runtime specific environment variables.

For PATH to work properly, it’s necessary not to hardcode any pathname in your code. For instance, don’t rely on /usr/bin/python or on /usr/bin/java but instead run python or java.

While using snapcraft, proper wrappers will be generated for binaries declared for your app. Snapcraft will also adjust symlinks to be relative and work for your snap.

Adding daemons

Every app may build a binary that may need to be exposed in the system, with that in mind, the way to expose a daemon is by using the daemon keyword. So, if there were two services, one called service1 and another called service2, the extract would look like

apps:
  daemon1:
    command: bin/app1
    daemon: simple
  daemon2:
    command: bin/app2 --start
    stop-command: bin/app2 --stop
    daemon: forking

So in the example, daemon will declare its start to the relative path bin/app1, while daemon2 defines a different start to bin/app2: it declares an explicit stop mechanism.

Also note that daemon1 is defined as a simple daemon, meaning that it is expected that the command configured is the main process. Daemons like daemon2 which use forking have the configured command call fork() as part of its start-up. The parent process is expected to exit when start-up is complete and all communication channels are set up. The child continues to run as the main daemon process. This is the behavior of traditional UNIX daemons.

Fixed assets

Desktop files

You can declare a desktop file from your app within an apps entry using a path relative to the prime directory pointing to a desktop file, snapcraft will take care of the rest. If your project already has a desktop file, say in /usr/share/applications/my-app.desktop all you need to do is the following:

apps:
    my-app:
        command: my-app
        desktop: usr/share/applications/my-app.desktop

Alternatively, you can create a setup/gui/ directory at the root of your snapcraft project to host a desktop file:

setup/gui/<app-name>.desktop
snapcraft.yaml

Where <app-name> is the entry corresponding to apps in snapcraft.yaml.

Package icons

Providing an icon for your snap is important, even for command-line applications, if for nothing else than discoverability from management interfaces such as store fronts like snapweb.

To use an icon to represent the snap, just declare a PNG or SVG in snapcraft.yaml through an icon entry with a path relative to the icon inside the snap.