snapcraft.yaml¶

This reference describes the purpose, usage, and examples of all available keys in a snap’s project file, snapcraft.yaml.

For keys that refer to file and directory locations, paths are always relative to the snap’s file system, not the host.

Top-level keys¶

The top-level keys dictate the snap’s packaging information and the essential details of how it builds.

Top-level details include a snap’s name, version and description, alongside operational values such as its confinement level and supported architectures.

name¶

Type

str

Description

The identifying name of the snap.

It must start with an ASCII character and can only contain lower case letters, numbers, and hyphens. It must contain at least one letter and it can’t start or end with a hyphen. The maximum length is 40 characters.

The name must be unique if you want to publish it to the Snap Store.

For help on choosing a name and registering it on the Snap Store, see Registering your app name.

Examples

name: my-app

name: powershell

name: jupyterlab-desktop

title¶

Type

str

Description

A human-readable title.

Examples

title: Ubuntu Linux

title: Jupyter Lab Desktop

title: LXD

title: DigiKam

title: Apache Kafka

title: MySQL Router K8s charm

version¶

Type

str

Description

The version of the snap.

This field is required unless version information is provided by the adopt-info key.

See Using external metadata for more information.

Examples

version: 1.2.3

license¶

Type

str

summary¶

Type

str

Description

A short description of your project.

Examples

summary: Linux for Human Beings

summary: The cross-platform desktop application for JupyterLab

summary: Container and VM manager

summary: Photo Management Program

summary: Charm for routing MySQL databases in Kubernetes

summary: An open-source event streaming platform for high-performance data pipelines

description¶

Type

str

adopt-info¶

Type

str

Description

Selects a part to inherit metadata from and reuse for the snap’s metadata.

Required if one of version, summary, or description isn’t set.

There are two ways to adopt metadata from a part:

Using the ‘craftctl set’ command in an ‘override-’ script.
Using appstream metadata files listed in the ‘parse-info’ field of the adopting part.

Examples

adopt-info: foo-part

type¶

Type

Any of: ['app', 'base', 'gadget', 'kernel', 'snapd']

Description

The snap’s type.

Values

Value	Description
`app`	Default. Set the snap as an application.
`base`	Set the snap as a base.
`gadget`	Set the snap as a gadget snap.
`kernel`	Set the snap as a kernel snap.
`snapd`	Set the snap as a snapd snap.

Examples

type: kernel

base¶

Type

str

build-base¶

Type

str

Description

The build environment to use when building the snap

Examples

build-base: core20

build-base: core22

build-base: core24

build-base: devel

grade¶

Type

Any of: ['stable', 'devel']

Description

The quality grade of the snap.

The grade can only be stable if the base and build-base are stable. For example, if the build-base is devel, then the grade must be devel.

The grade must be stable to publish the snap to the candidate or stable channels on the snap store. If the grade is devel, it can only be published to the beta and edge channels.

Values

Value	Description
`stable`	Default. The snap is stable.
`devel`	The snap is still under development.

Examples

grade: stable

grade: devel

confinement¶

Type

Any of: ['classic', 'devmode', 'strict']

Description

The amount of isolation the snap has from the host system.

Snap confinement determines the amount of access an application has to system resources, such as files, the network, peripherals and services.

For core22 and newer bases, confinement is a required property and has no default value.

For more information, see Confinement.

Values

Value	Description
`strict`	Default for core20 and older bases. Use strict confinement.
`classic`	Use classic confinement.
`devmode`	Use devmode confinement.

Examples

confinement: strict

confinement: classic

confinement: devmode

source-code¶

Type

list

Description

The links to the source code of the snap or the original product.

Source code links can be adopted from appstream metadata files.

See using external metadata for more information.

Examples

source-code:
  - https://example.com/source-code

contact¶

Type

list

Description

The snap author’s contact links and email addresses.

Contact information can be adopted from appstream metadata files.

See using external metadata for more information.

Examples

contact:
  - [email protected]
  - https://example.com/contact

website¶

Type

list

Description

The links to the original software’s web pages.

Websites can be adopted from appstream metadata files.

See using external metadata for more information.

Examples

website:
  - https://example.com

issues¶

Type

list

Description

The links and email addresses for submitting issues, bugs, and feature requests.

Issue links can be adopted from appstream metadata files.

See using external metadata for more information.

Examples

issues:
  - [email protected]
  - https://example.com/issues

donation¶

Type

list

Description

The snap’s donation links.

Donation links can be adopted from appstream metadata files.

See Using external metadata for more information.

Examples

donation:
  - [email protected]
  - https://example.com/donate

compression¶

Type

Any of: ['lzo', 'xz']

Description

Specifies the algorithm that compresses the snap.

Snaps are compressed using xz data compression by default. This offers the optimal performance to compression ratio for the majority of snaps.

However, there are certain types of snap, such as large desktop applications, that can benefit from using LZO compression. Snaps compressed with LZO are slightly larger but can decompress quicker, reducing the time it takes for freshly installed or refreshed snaps to launch.

Values

Value	Description
`xz`	Default. Use XZ compression.
`lzo`	Use LZO compression.

Examples

compression: xz

compression: lzo

icon¶

Type

str

Description

The path to the snap’s icon.

Icon size can be between 40x40 and 512x512 pixels. 256x256 is recommended. The file should be less than 256 KB.

The icon is used in the snap store and other graphical store fronts. The icon defined in the .desktop file is used as the icon in desktop menus.

Examples

icon: snap/gui/icon.svg

layout¶

Type

Any of: ['symlink', 'bind', 'bind-file', 'type']

Description

The file layouts in the execution environment.

Layouts modify the execution environment of a strictly-confined snap.

With layouts, you can make elements in $SNAP, $SNAP_DATA, $SNAP_COMMON accessible from locations such as /usr, /var and /etc. This helps when using pre-compiled binaries and libraries that expect to find files and directories outside of locations referenced by $SNAP or $SNAP_DATA.

See snap layouts for more details.

Values

Value	Description
`symlink: <source-path>`	Create a symbolic link. This method is preferred because it is the cheapest; the other methods significantly increase the startup time of your application
`bind: <source-path>`	Bind-mount a directory.
`bind-file: <source-path>`	Bind-mount a file.
`type: tmpfs`	Mount a private, temporary, in-memory filesystem

Examples

layout:
  /var/lib/foo:
    bind: $SNAP_DATA/var/lib/foo

passthrough¶

Type

dict

Description

The attributes to pass to the snap’s metadata file.

These attributes are passed to snap.yaml without validation from Snapcraft. This is useful for early testing of a new feature in snapd that isn’t yet supported by Snapcraft.

To pass a value for a particular app, see the passthrough key for apps.

See Using development features in Snapcraft.

Examples

passthrough:
  daemon: complex

assumes¶

Type

list

Description

The minimum version of snapd and its features that the snap requires from the host.

If the host doesn’t meet any of the requirements, snapd won’t install the snap.

You can declare both a snapd version and its features at the same time.

List a minimum version of snapd with snapd<version>.

List required snapd features by name:

common-data-dir for the common data directory across revisions of a snap.
snap-env for declaring runtime environment variables in the project file.
command-chain for chaining commands in apps and hooks in the project file.
kernel-assets for kernel assets declared in a gadget snap project file.

Examples

assumes:
  - snapd2.66
  - common-data-dir

slots¶

Type

dict

Description

Declares the snap’s slots.

Examples

slots:
  slot-1:
    content: my-binaries
    interface: content
    source:
      read:
        - $SNAP/bin

lint¶

Type

Lint

Description

The linter configuration settings.

Snapcraft runs the following linters:

classic: Verifies binary file parameters for snaps using classic confinement.
library: Verifies that no ELF file dependencies, such as libraries, are missing and that no extra libraries are included in the snap package.

See Snapcraft linters for more information.

Examples

lint:
  ignore:
    - classic
    - library:
      - usr/lib/**/libfoo.so*

epoch¶

Type

str

Description

The epoch associated with this version of the snap.

Controls when users receive configuration-breaking application releases and ensures upgrades migrate through each epoch.

Asterisks after the epoch denote it can read configuration data from the previous epoch.

This is an uncommonly used keyword.

See snap epochs for more information.

Examples

epoch: 1

epoch: 2*

system-usernames¶

Type

dict

Description

The system usernames that the snap can use to run daemons and services.

This is used to use the snapd defined user snap_daemon run a daemon. Otherwise, this is an uncommonly used vaiue.

See system usernames for more information.

Examples

system-usernames:
  snap-daemon: shared

environment¶

Type

dict

Description

The snap’s runtime environment variables.

Environment variables are set at runtime for all apps. To set an environment variable for a particular app, use the environment key for that app entry.

Examples

environment:
  DISABLE_WAYLAND: 1
  PYTHONPATH: $SNAP/usr/lib/python3/dist-packages:$PYTHON_PATH

build-packages¶

Type

GrammarScalar

Description

The list of packages to install when building a snap.

All build packages are installed before any part is built. However, if a package is only needed for one part, it is recommended to use the build-packages key for that part. This organization makes it easier to track which parts require which build packages.

Examples

build-packages:
  - libssl-dev
  - libyaml-dev

build-snaps¶

Type

GrammarScalar

Description

The snaps to install when building a snap.

If only the snap name is provided, the snap will be installed from the latest/stable channel.

Otherwise, a channel can be specified with <name>/<channel>.

Examples

build-snaps:
  - go/1.22/stable
  - yq

ua-services¶

Type

set

Description

The Ubuntu Pro (formerly Ubuntu Advantage) services to enable when building the snap.

Enabling Ubuntu Pro services allows building snaps in an Ubuntu Pro enabled environment.

Examples

ua-services:
  - esm-apps

provenance¶

Type

str

Description

The primary-key header for snaps signed by third parties.

This is an uncommonly used value.

Examples

provenance: test-provenance

platforms¶

Type

dict

Description

The platforms where the snap can be built and where the resulting snap can run.

If the platform name is a valid debian architecture, build-on and build-for can be omitted.

The platform name describes a build-on/build-for pairing. When specifying build-on and build-for, the the name is arbitrary but it’s recommended to set the platform name to the build-for architecture.

The platforms keyword is only used in core24 and newer snaps. For core22 and older snaps, use the architectures key.

Examples

platforms:
  amd64:
    build-for:
      - amd64
    build-on:
      - amd64
  arm64:
    build-for:
      - arm64
    build-on:
      - amd64
      - arm64

architectures¶

Type

list

Description

The architecture sets where the snap can be built and where the resulting snap can run.

The architectures keyword is only used in core22 and older snaps. For core24 and newer snaps, use the platform key.

Architectures may be defined as a shorthand list of architectures or a explicit pair of build-on/build-for entries.

Examples

architectures:
  - amd64
  - riscv64

architectures:
  - build-for:
    - amd64
  build-on:
    - amd64

architectures:
  - build-for:
    - riscv64
  build-on:
    - amd64
    - riscv64

apps¶

Type

dict

Description

The map of app names representing entry points to run for the snap.

Apps are used to expose applications and services for the snap, how they are run, and which resources they can access.

If the app name is the same as snap name, the app will be run when the snap is run as app-name.

If they differ, the program will be exposed as ‘<snap-name>.<app-name>’.

Examples

apps:
  app-1:
    command: bin/app-1

parts¶

Type

dict

package-repositories¶

Type

list

hooks¶

Type

dict

Description

Configures the snap’s hooks.

Examples

hooks:
  configure:
    plugs:
      - home

components¶

Type

dict

Description

Declares the components to build in conjunction with the snap.

Examples

components:
  foo-component:
    type: standard

plugs¶

Type

dict

Description

Declares the snap’s plugs.

Examples

plugs:
  dot-gitconfig:
    interface: personal-files
    read:
      - $HOME/.gitconfig

App keys¶

The apps key declares the programs and services that a snap operates on the host, and details how they’re executed and which resources they can access.

Snapcraft project app definition.

apps.<app-name>.command¶

Type

str

Description

The command to run inside the snap when the app is invoked.

The command can be in either a snap runtime’s command path, $SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin, or an executable path relative to $SNAP.

The command must consist only of alphanumeric characters, spaces, and the following special characters: /, ., _, #, :, $, -. If other characters are required, a wrapper script should be used for the command.

If the daemon is set, this will be the command to run the service. Only a snap with classic confinement can use a relative path because PATH isn’t modified by a wrapper in classic confinement. See Classic confinement for more details.

Examples

command: bin/foo-app

apps.<app-name>.autostart¶

Type

str

Description

The desktop file used to start an app when the desktop environment starts.

The desktop file is placed in $SNAP_USER_DATA/.config/autostart and the app is launched by the app’s command wrapper (<name>.<app>) plus any argument present in the Exec= line in the .desktop file when the desktop environment is started.

See Autostart desktop files for an example of both the desktop file and the Exec file entry.

Examples

autostart: foo-app.desktop

apps.<app-name>.common-id¶

Type

str

Description

The identifier to a desktop ID within an external appstream file.

See Using external metadata for more information.

Examples

common-id: org.canonical.foo

apps.<app-name>.bus-name¶

Type

str

Description

The bus name that the application or service exposes through D-Bus.

Examples

bus-name: org.bluez

apps.<app-name>.desktop¶

Type

str

Description

The desktop file used to start an app.

See Desktop files for more information.

Examples

desktop: my-app.desktop

apps.<app-name>.completer¶

Type

str

Description

The name of the bash completion script for the app.

Examples

completer: bash-complete.sh

apps.<app-name>.stop-command¶

Type

str

Description

The command to run to stop the service.

Requires the daemon keyword to be specified for the app.

This allows a daemon to gracefully stop or restart, such as when a snap refresh occurs.

See Services and daemons for more information.

Examples

stop-command: bin/foo-app --halt

apps.<app-name>.post-stop-command¶

Type

str

Description

The command to run after the service is stopped.

Requires the daemon keyword to be specified for the app.

This allows a daemon to gracefully stop or restart, such as when a snap refresh occurs.

See Services and daemons for more information.

Examples

post-stop-command: bin/logrotate --force

apps.<app-name>.start-timeout¶

Type

str

Description

The maximum amount of time to wait for the service to start.

If the service does not start before the start-timeout elapses, then snapd will take further action based on the restart-condition keyword in the app.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Examples

start-timeout: 10s

start-timeout: 2m

apps.<app-name>.stop-timeout¶

Type

str

Description

The maximum amount of time to wait for the service to stop.

If the service does not stop before the stop-timeout elapses, then snapd will send a SIGTERM signal. If the service still does not stop, snapd will send a SIGKILL signal.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Examples

stop-timeout: 10s

stop-timeout: 2m

apps.<app-name>.watchdog-timeout¶

Type

str

Description

The maximum amount of time the service can run without sending a heartbeat to the watchdog.

For the watchdog to work, the application must have access to the systemd notification socket by specifying daemon-notify plug in the apps plugs definition.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Examples

watchdog-timeout: 10s

watchdog-timeout: 2m

apps.<app-name>.reload-command¶

Type

str

Description

The command to run to restart the service.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Examples

reload-command: bin/foo-app --restart

apps.<app-name>.restart-delay¶

Type

str

Description

The time to wait between service restarts.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Examples

restart-delay: 10s

restart-delay: 2m

apps.<app-name>.timer¶

Type

str

Description

The time or schedule to run a service.

The timer field uses a flexible syntax to schedule when a service should run.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Examples

timer: 1380

timer: 00:00-24:00/24

timer: mon,10:00,,fri,15:00

apps.<app-name>.daemon¶

Type

Any of: ['simple', 'forking', 'oneshot', 'notify', 'dbus']

Description

Configures the app as a service, and sets its runtime and notification behavior.

See Services and daemons for more information.

Values

Value	Description
`simple`	Run as long as the service is active. This is the most common option.
`forking`	The app’s `command` will call `fork()` as part of its start-up and the parent process is expected to exit when start-up is complete. This is used to support legacy fork-based Unix daemons.
`oneshot`	Run once and exit after completion, notifying systemd. After completion, the daemon is still considered active and running.
`notify`	Allows the service to be managed by systemd. Requires the service to send signals to the systemd notification socket by specifying `daemon-notify` in the app’s `plugs` definition.
`dbus`	Registers a D-Bus name to notify systemd. Requires ``bus-name or `activates-on` to be specified.

Examples

daemon: simple

daemon: oneshot

apps.<app-name>.after¶

Type

list

Description

The ordered list of apps that the service runs after it launches.

The apps must be part of the same snap.

Requires the daemon keyword to be specified for the app. Apps in the after keyword must also specify the daemon keyword.

See Services and daemons for more information.

Examples

after:
  - foo-app
  - bar-app

apps.<app-name>.before¶

Type

list

Description

The ordered list of apps that the service runs before it launches.

The apps must be part of the same snap.

Requires the daemon keyword to be specified for the app. Apps in the before keyword must also specify the daemon keyword.

See Services and daemons for more information.

Examples

before:
  - baz-app
  - quz-app

apps.<app-name>.refresh-mode¶

Type

Any of: ['endure', 'restart', 'ignore-running']

Description

Determines how the service should restart when the snap refreshes.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Values

Value	Description
`restart`	Restart the service when the snap is refreshed. Default.
`endure`	Do not restart the service when the snap is refreshed.
`ignore-running`	Do not refresh the snap if the service is running.

Examples

refresh-mode: restart

apps.<app-name>.stop-mode¶

Type

Any of: ['sigterm', 'sigterm-all', 'sighup', 'sighup-all', 'sigusr1', 'sigusr1-all', 'sigusr2', 'sigusr2-all', 'sigint', 'sigint-all']

Description

The signal to send when stopping the service.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Examples

stop-mode: sigterm

apps.<app-name>.restart-condition¶

Type

Any of: ['on-success', 'on-failure', 'on-abnormal', 'on-abort', 'on-watchdog', 'always', 'never']

Description

The conditions that cause the service to restart.

The conditions for restart-condition match those defined by systemd. See the systemd manual for information on what exit codes will trigger a restart for each condition.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Examples

restart-condition: on-failure

apps.<app-name>.install-mode¶

Type

Any of: ['enable', 'disable']

Description

Whether snapd can automatically start the service when the snap is installed.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Values

Value	Description
`enable`	The service is started when the snap is installed. Additionally, if the snap was installed without a service, then the snap is refreshed to include a service. This will start the service too.
`disable`	The service is not automatically started. Instead, the service will be started with snapctl and another management agent, which is most commonly a hook.

Examples

install-mode: enable

apps.<app-name>.slots¶

Type

list

Description

The list of slots that the app provides.

Slot connections are only made when the snap is running in strict confinement.

Slots are used to define what code and data can be shared with other snaps.

See the content interface for more information about plugs and slots.

Examples

slots:
  - dbus-daemon

apps.<app-name>.plugs¶

Type

list

Description

The list of interfaces that the app can connect to.

See the content interface for more information about plugs and slots.

Examples

plugs:
  - home
  - removable-media

apps.<app-name>.aliases¶

Type

list

Description

The aliases that can be used to run the app.

See Commands and aliases for more information.

Examples

aliases:
  - my-app

apps.<app-name>.environment¶

Type

dict

Description

The runtime environment variables.

To set an environment variable for all apps, use the top-level environment key.

Examples

environment:
  DISABLE_WAYLAND: 1
  PYTHONPATH: $SNAP/usr/lib/python3/dist-packages

apps.<app-name>.command-chain¶

Type

list

Description

The ordered list of commands to run before the app’s command runs.

Command chains are useful to run setup scripts before running an app.

Examples

command-chain:
  - bin/alsa-launch
  - bin/desktop-launch

apps.<app-name>.sockets¶

Type

dict

Description

The sockets used to activate an app.

Requires the network-bind interface in the app’s plug keyword.

This value is used for services that are activated by a connection to a socket.

Examples

sockets:
  my-socket:
    listen-stream: $SNAP_COMMON/lxd/unix.socket
    socket-mode: 432

apps.<app-name>.daemon-scope¶

Type

Any of: ['system', 'user']

Description

Determines whether the service is run on a system or a user instance of systemd.

See Enabling user daemons for more information on how snapd manages daemon scope.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Values

Value	Description
`system`	Run the service under the system instance of systemd.
`user`	Run the service under a user-session instance of systemd.

Examples

daemon-scope: user

apps.<app-name>.activates-on¶

Type

list

Description

The slots exposed by the snap to activate the service with D-Bus.

This is useful for services that are activated by other applications or services.

See D-Bus activation for more information on how snapd activates services with D-Bus.

Requires the daemon keyword to be specified for the app.

See Services and daemons for more information.

Examples

activates-on: gnome-shell-dbus

apps.<app-name>.passthrough¶

Type

dict

Description

The attributes to pass to the snap’s metadata file for the app.

Attributes to passthrough to snap.yaml without validation from Snapcraft. This is useful for early testing of a new feature in snapd that isn’t supported yet by Snapcraft.

To pass a value for the entire project, see the top-level passthrough key.

See Using development features in Snapcraft for more details.

Examples

passthrough:
  daemon: complex

Type

int

Description

The socket’s abstract name or socket path.

TCP and UNIX sockets are supported.

Examples

listen-stream: $SNAP_COMMON/lxd/unix.socket

listen-stream: 80

sockets.<socket-name>.socket-mode¶

Type

int

Description

The mode or permissions of the socket in octal.

Examples

socket-mode: 432

Hook keys¶

Snapcraft project hook definition.

hooks.<hook-type>.command-chain¶

Type

list

Description

The ordered list of commands to run before the hook runs.

Command chains are useful to run setup scripts before running a hook.

Examples

command-chain:
  - bin/alsa-launch
  - bin/desktop-launch

hooks.<hook-type>.environment¶

Type

dict

Description

The environment variables for the hook.

Examples

environment:
  DISABLE_WAYLAND: 1
  PYTHONPATH: /custom/path/:$PYTHON_PATH

hooks.<hook-type>.plugs¶

Type

list

Description

The list of interfaces that the hook can connect to.

See the content interface for more information about plugs and slots.

Examples

plugs:
  - home
  - removable-media

hooks.<hook-type>.passthrough¶

Type

dict

Description

The attributes to pass to the snap’s metadata file for the hook.

Attributes to passthrough to snap.yaml without validation from Snapcraft. This is useful for early testing of a new feature in snapd that isn’t supported yet by Snapcraft.

To pass a value for the entire project, see the top-level passthrough key.

See Using development features in Snapcraft for more details.

Examples

passthrough:
  daemon: complex

Component keys¶

Snapcraft component definition.

components.<component-name>.summary¶

Type

str

Description

The summary of the component.

This is a freeform field used to describe the purpose of the component.

Examples

summary: Language translations for the app

components.<component-name>.description¶

Type

str

Description

The multi-line description of the component.

This is a freeform field used to describe the purpose of the component.

Examples

description: Contains optional translation packs to allow the user to change the language.

components.<component-name>.type¶

Type

Any of: ['test', 'kernel-modules', 'standard']

Description

The type of the component.

Different component types may have special handling by snapd.

Values

Values	Description
`standard`	General use type. Use when no specific type applies.
`kernel-modules`	For kernel modules in snaps with type `kernel`.

Examples

type: standard

components.<component-name>.version¶

Type

str

Description

The version of the component.

If the version is not provided, the component will be unversioned.

Examples

version: 1.2.3

components.<component-name>.hooks¶

Type

dict

Description

The configuration for the component’s hooks.

Examples

hooks:
  configure:
    plugs:
      - home

Content plug keys¶

Snapcraft project content plug definition.

plugs.<plug-name>.content¶

Type

str

Description

The name for the content type.

This is an arbitrary identifier for content interfaces. If it is not specified, it will default to the plug’s name.

Examples

content: themes

plugs.<plug-name>.interface¶

Type

str

Description

The name of the interface.

See Supported interfaces for a list of supported interfaces.

When using the content interface, this should be set to content.

Examples

interface: network

plugs.<plug-name>.target¶

Type

str

Description

The path to where the producer’s files will be available in the snap.

This is only needed when using the content interface. See the Content interface for more information.

Examples

target: $SNAP/data-dir/themes

plugs.<plug-name>.default-provider¶

Type

str

Description

The name of the producer snap.

This is only needed when using the content interface. See the Content interface for more information.

Examples

default-provider: gtk-common-themes