content-interface¶
The content interface allows sharing code and data from a slot on a producer snap to one or more plugs on consumer snaps. It’s often used to share common themes and icons from a producer snap, for example, to many snapped applications.
Sharing happens at the filesystem level, which means anything that can be expressed as a file can be shared. This includes executables, libraries and data files, but also sockets.
Example
The Yaru MATE Icons snap is a good producer snap example, letting other applications access the wonderful MATE icon theme. But there are many other producer snaps too, including several for GTK Common Themes and KDE Frameworks for better application integration with the desktop.
Tip
See Interface management and Supported interfaces for further details on how interfaces are used.
Developer details
Auto-connect: no, unless connecting to snaps from the same publisher.
Attributes:
source (slot): allows multiple directories to be exposed separately rather than grouped together
read (slot): read-only paths to be exposed to a consuming snap
write (slot): read and write paths to be exposed to a consuming snap
target (plug): path in consuming snap to find producer snap’s files
default-provider (plug): name of preferred producer snap (
<SNAP>)content (slot and plug): an arbitrary identifier for content type. Defaults to either local slot name or local plug name for slot/plug definitions respectively.
interface (slot and plug): snapd interface name (must be
interface: content)
See below for more details on the following:
Sharing content: how to share filesystem locations, and how they appear to a plug
Using the source keyword: share one or more sub-directories beneath a target path
Read-only content sharing: ideal for executables and global graphical themes
Content identifier obligations: how the content identifier represents a compatibility contract between the producer and consumer snaps
Default provider: define and potentially install a snap with a corresponding slot
Writable data: share data files and sockets between one or more snaps
Implementation details: how AppArmor and bind mounts help implement the interface
Sharing content
By default, when multiple directories are shared from a producer snap, or when multiple slots are connected to a single plug, the shared content is merged under the target path of the consuming path’s plug definition. This behaviour can be modified with the source attribute.
Read, write and target should start with either $SNAP, $SNAP_DATA or $SNAP_COMMON to refer to the designated directory. See Environment variables for details on where these point to on the filesystem.
The content identifier specified by the consuming snap (plug) must match the content attribute of the producer snap (slot).
At a very basic level, the content interface enables one directory, file or socket to appear in a place where another snap can access it.
Each example below involve two snaps: the first provides some content (using a content slot) while the second consumes that content (using a content plug).
In all of the cases we see a small set of attributes defined on the particular interface:
the producer declares which path can be read, using either the
readattribute for read-only, or thewriteattribute for both read and write permissionsthe consumer uses the
targetattribute to define where the content should become available at runtime.both the producer and consumer use an arbitrary
contentattribute to describe the content. This attribute must match on both sides for the connection to happen.
Using source
The source attribute presents one or more sub-directories, shared from a slot to a plug, beneath the plug’s target path. Adding the source attribute ensures that sub-directories, shared from one or more producer snaps, are presented separately to the consumer snap beneath its target path.
When multiple slots are connected to the same plug and they share directories with the same name, those directories are given unique names with the following pattern: <directory>, <directory>-2, <directory>-3, <directory>-x. The names of shared directories with unique names are retained, as defined by the slot.
With the following example, directories from the producer snap are shared in corresponding directories beneath the consumer snap’s target path:
producer/snapcraft.yaml:
slots:
_slot_name_:
interface: content
content: my-binaries
source:
read:
- $SNAP/bin
consumer/snapcraft.yaml:
plugs:
_plug_name_:
interface: content
content: my-binaries
target: $SNAP/usr/local/bin
Using the above configuration, the consumer snap could implement a part to run an executable from the following path:
$SNAP/usr/local/bin/<executable-name>
When more than one slot is connected to the same plug, the plug directory for the new connection will be incremented:
$SNAP/usr/local/bin-2/<executable-name>
Directory names are preserved after a reboot.
Read-only content sharing
Read-only content sharing is ideal for executables and files related to global graphical themes and images.