Adding interfaces

doc
1

After Defining a command, interfaces are the means by which an installed snap gets access to system resources. Interfaces that are required for normal operation are specified at snap build-time within the app and service metadata of a snap’s snapcraft.yaml.

Many interfaces are automatically connected when a snap is installed, but this ability is dependent on the permissiveness of each particular interface. See Auto-connections for more details.

Other interfaces require the user to make a manual connection, such as camera and removable-media. Manual connections enable the user to have a complete control over what kind of access they allow.

Once published in the Snap Store, automatic connections may be requested for manual interfaces on a case-by-case basis. For example, it may be reasonable for a photo-booth application to expect an automatic connection to the camera interface. Those requests are submitted and processed in the open on the Snapcraft forum. For more details on this process, see Permission requests .

Plugs and slots

Interfaces are implemented as plugs and slots. A plug in one snap may connect to a slot in another and this provides access to the resources required. For example the ohmygiraffe snap specifies the opengl plug which connects to the opengl slot provided elsewhere - in this case by the core snap.

Users may view the interfaces used as a list of plugs and slots via the snap connections command:

$ snap connections ohmygiraffe
Interface     Plug                      Slot           Notes
network       ohmygiraffe:network       :network       -
network-bind  ohmygiraffe:network-bind  :network-bind  -
opengl        ohmygiraffe:opengl        :opengl        -
pulseaudio    ohmygiraffe:pulseaudio    :pulseaudio    -
x11           ohmygiraffe:x11           :x11           -

Developers specify a list of plugs for each application inside a snap being exposed to the host OS. Each application may have a different set of plugs specified. Developers should endeavour to list only the plugs required for normal operation of the application.

In a simplified example, a snap which contains both a server, which connects to a webcam to stream online, and a graphical application, to view the camera, may have interfaces listed as follows:

apps:
  streamer:
    command: bin/streamer-cli
    plugs:
      - network-bind
      - camera
  frontend:
    command: bin/frontend-gui
    plugs:
      - network
      - camera
      - x11

:information_source: The state of a connection can be checked within a snap using the snapctl utility. See Using the snapctl tool for further details.

Common interfaces

When building a snap, its interfaces will be as unique as its application requirements. You can use the snappy-debug tool to figure out which interfaces a snap needs.

The FFmpeg multimedia framework, for example, needs interfaces for audio, USB cameras, network access and the desktop, among many others. The game Spelunky needs to access OpenGL, the desktop environment and any connected joystick.

The process of adding interfaces requires the snap developer to have a good understanding of the applications it contains, but there are certain categories of snap that require the same, or very similar, sets of interfaces.

Being familiar with these can help to speed up snap development:

See Supported interfaces for the full list of interfaces available for snaps to use.

2

@degville I noticed that this link here for the network interface documentation takes you directly to the network-interface thread in the Snapcraft Forum rather than the front-end page https://snapcraft.io/docs/network-interface

3

Offtopic, but triggered by the reply @nuccitheboss left here. Is it worth us changing ownership of all these docs pages to a non-human account, rather than having my name all over them :smiley:

I don’t mind, I just look at the notification and think “Someone loves me” :heart: then realise it’s just a conversation about a wiki page I helped write 4 years ago.

Just wondered. I know some people like their names on things, so they get credit. I don’t really care, just thought it might make things ‘tidy’?

1 Like
4

I agree. I saw your name so that’s why I tagged Graham :smiley:

We could set up a system account similar to the one we have on the Ubuntu Discourse: Profile - system - Ubuntu Community Hub. @AaronPrisk do you think you could potentially us out here? IIRC you helped with setting up the system account when we introduced the events plugin.

1 Like
5

Hello @nuccitheboss! Thanks for flagging this. I hadn’t realised, but there were two separate docs for the network-interface. I’ve now moved the content from @popey’s doc into the one that’s being published and updated the link, so this should fix the problem.

6

I’m certainly happy to change the ownership on @popey’s documentation posts if this will help.

We already have a @system user, which we’ve used in the past. I don’t have strong feelings about this, as it’s not reflected in the published version of the docs, and documents typically change a lot, by several people, after they’ve been created.

But we also have a few community contributions, and I think it’s quite a nice kudos for them to be seen as the originators

1 Like
7

That’s true; attribution is important.

Perhaps we could do something similar to the Juju documentation where we have a section at the bottom of the page that has the list of contributors who have made substantial improvements to that piece of documentation: Juju | Get started with Juju

The primary author could be listed first, and other contributors listed after that. That way the documentation in Discourse could be owned by a @system user so no one person is responsible for it, but folks will still get the proper credit that they are due. What do you think of that?

1 Like
8

Both options make sense to me. It looks like there was also a @wiki account that has some documentation attributed to it. I tend to like @nuccitheboss’s idea of changing their ownership to a generic account that will always be around and a listing contributors somewhere within.

9

I’m not too keen on the contributions at the bottom of each published page. It’s great for the contributors - and they should absolutely be recognised - but it adds unnecessary noise to every single page.

There are also cases where a community member has written documentation and they’ll want to be notified about changes to their own documentation. This is easier if their account is still associated with the page they originated. Maybe the contributors themselves should have the choice.