Why not fix snap interfaces
to be more readable? What use case is there for having both interfaces
and connections
- when would I use one over the other?
I like the ordering by plug name, then by slot name. This matches how we work on connect/disconnect (order of plug and slot) and how people think of connections (mostly about what a given snap contains, so by-snap order makes sense).
Questions:
- Should we abbreviate
core:home
to just:home
? - Should we print the plug/slot headers?
- How should it look like before we have any connections?
- What should happen if we ask about a specific connection
snap connection spotify:home
Note that I used the singular word connection
in my last question above.
The old snap interfaces
command is going to get deprecated and go away over time. We don’t want to break how it works for now.
Per zyga’s suggestion, we can turn core:foo
into :foo
as that’s both cleaner and supported in the connect and disconnect commands.
We should have some better details there, otherwise it feels like we’re not really improving much over what we have today. How about starting with an “Interface” column, and adding a “Notes” at the end:
Plug Slot Interface Notes
spotify:home :home home -
spotify:video :camera camera manual
Also, how about filtering the list so that:
- Without any parameters, only show connected interfaces
- With --all, show both connected and disconnected interfaces
- With a snap name, show both connected and disconnected interfaces
Update: I’ve inverted the order of the columns so Plug and Slot come first. That seems better because those are the two most relevant things, which are actually typed in command lines for connections and disconnections.
Let’s say I only had the core snap installed, and I wanted to see all slots available on it. Would that look like this?
$ snap connections core
Plug Slot
- core:home
- core:mount-observe
- core:unity7
# ...
Per my suggestion above at least, no… it would have extra columns and the “core” string wouldn’t be present in all of those lines.
Did some experiments, and this is what I have.
Connections of a single snap:
$ snap connections gnome-sudoku
Plug Slot Interface Notes
gnome-sudoku:desktop :desktop desktop -
gnome-sudoku:desktop-legacy :desktop-legacy desktop-legacy -
gnome-sudoku:gnome-3-26-1604 gnome-3-26-1604:gnome-3-26-1604 content -
gnome-sudoku:gsettings :gsettings gsettings -
gnome-sudoku:gtk-3-themes gtk-common-themes:gtk-3-themes content -
gnome-sudoku:icon-themes gtk-common-themes:icon-themes content -
gnome-sudoku:pulseaudio :pulseaudio pulseaudio -
gnome-sudoku:sound-themes gtk-common-themes:sound-themes content -
gnome-sudoku:unity7 :unity7 unity7 -
gnome-sudoku:wayland :wayland wayland -
Snap that is content provider:
$ snap connections gtk-common-themes
Plug Slot Interface Notes
gnome-calculator:gtk-3-themes gtk-common-themes:gtk-3-themes content -
gnome-calculator:icon-themes gtk-common-themes:icon-themes content -
gnome-calculator:sound-themes gtk-common-themes:sound-themes content -
gnome-sudoku:gtk-3-themes gtk-common-themes:gtk-3-themes content -
gnome-sudoku:icon-themes gtk-common-themes:icon-themes content -
gnome-sudoku:sound-themes gtk-common-themes:sound-themes content -
Snap that does not use content:
$ snap connections vlc
Plug Slot Interface Notes
vlc:desktop :desktop desktop -
vlc:desktop-legacy :desktop-legacy desktop-legacy -
vlc:home :home home -
vlc:network :network network -
vlc:network-bind :network-bind network-bind -
vlc:opengl :opengl opengl -
vlc:optical-drive :optical-drive optical-drive -
vlc:pulseaudio :pulseaudio pulseaudio -
vlc:removable-media :removable-media removable-media -
vlc:screen-inhibit-control :screen-inhibit-control screen-inhibit-control -
vlc:unity7 :unity7 unity7 -
vlc:x11 :x11 x11 -
But has some disconnected interfaces:
$ snap connections vlc -a
Plug Slot Interface Notes
vlc:camera - camera -
vlc:desktop :desktop desktop -
vlc:desktop-legacy :desktop-legacy desktop-legacy -
vlc:home :home home -
vlc:mount-observe - mount-observe -
vlc:network :network network -
vlc:network-bind :network-bind network-bind -
vlc:opengl :opengl opengl -
vlc:optical-drive :optical-drive optical-drive -
vlc:pulseaudio :pulseaudio pulseaudio -
vlc:removable-media :removable-media removable-media -
vlc:screen-inhibit-control :screen-inhibit-control screen-inhibit-control -
vlc:unity7 :unity7 unity7 -
vlc:x11 :x11 x11 -
- vlc:mpris mpris -
Snap that has just one plug but it’s not connected by default:
$ snap connections test-services-25269
no connections found
$ snap connections test-services-25269 -a
Plug Slot Interface Notes
test-services-25269:daemon-notify - daemon-notify -
I would like to get to the following for manually connected plugs:
$ snap connections test-services-25269
Plug Slot Interface Notes
test-services-25269:daemon-notify :daemon-notify daemon-notify manual
Extending this further for hotplug
:
$ snap connections test-services-25269
Plug Slot Interface Notes
service1:uart :qemuserialusb serial-port manual,hotplug
service2:uart :qemuserialusb serial-port hotplug
This involves some changes to the daemon API. The information on whether a connection is manua/hotplug related is not directly available through the API at this point.
A quick observation, maybe it’s just implementation/formatting detail, but this output feels a bit overwhelming and takes a 1.5 full pages on my terminal:
$ snap connections -a
Plug Slot Interface Notes
gnome-calculator:desktop :desktop desktop -
gnome-calculator:desktop-legacy :desktop-legacy desktop-legacy -
...
- :screencast-legacy screencast-legacy -
- :shutdown shutdown -
- :ssh-keys ssh-keys -
- :ssh-public-keys ssh-public-keys -
- :system-trace system-trace -
- :time-control time-control -
- :timeserver-control timeserver-control -
- :timezone-control timezone-control -
- :tpm tpm -
...
Perhaps we could make the snap name required and instead suggest to the user to use snap connections system
instead.
wan’t the plan to also add a new api endpoint for this as well? maybe @zyga-snapd remembers whether that was the case
AFAIK we 100% wanted a new endpoint for this.
FYI I’ve opened https://github.com/snapcore/snapd/pull/6079 a while ago where we can discuss output formatting and so on. The code does this on the old endpoints, so it’s obviously missing the data on why an interface is connected or disconnected.
Since the output is there, maybe it would make sense to land it at some point just to introduce the command and then work on the backend bits to fill the notes column with useful info.
I’m thinking about a reasonable way of presenting connections that are undesired, i.e. disconnected manually by the user.
Just to recap what was already written above, snap connections foo
, by default shows only connected plugs and slots:
$ snap connections foo
Plug Slot Interface Notes
foo:plug bar:slot iface -
Suppose that interface iface
is auto connected, but the user has issued snap disconnect foo:plug2
before. Snapd will internally track the connection foo:plug2 baz:slot
as undesired, so on the next refresh, it will not be automatically reconnected. We can show both endpoints of such connection in snap connections
output, since both are known. I think we could present it to the user like this (note you’d have to pass -a
):
$ snap connections foo -a
Plug Slot Interface Notes
foo:plug bar:slot iface -
foo:plug2 baz:slot iface disconnected,manual
foo:plug3 - non-auto -
Thoughts?
Even with -a
flag, IMHO it still feels strange and a little bit confusing to show:
foo:plug2 baz:slot iface disconnected,manual
(I’m trying to think about an alternative, no good idea yet).
UPDATE: perhaps a dedicated flag to only show undesired (disconnected) auto-connections and nothing else?
It’s tricky. If the default behaviour is to list only connected interfaces then indeed manually disconnected ones wouldn’t appear, but also the user would be none the wiser both of these (which presumably they’d know about) but also about potentially useful manually connected ones.
I think one way out would be to always print a one-line summary before (if it’s a summary of everything) or after (if it’s a summary of what’s not shown) the listing (always being key to it being script-friendly). Something like
$ snap connections foo
Plug Slot Interface Notes
foo:plug bar:slot iface -
2 interfaces on foo are not connected (see -a).
$ snap connections -a foo
Plug Slot Interface Notes
foo:plug bar:slot iface -
foo:plug2 baz:slot iface disconnected,manual
foo:plug3 - non-auto -
No further interfaces exist for foo.
or
$ snap connections foo
snap "foo" has 3 interfaces, of which 1 is connected:
Plug Slot Interface Notes
foo:plug bar:slot iface -
$ snap connections -d foo
snap "foo" has 3 interfaces, of which 2 are disconnected:
Plug Slot Interface Notes
foo:plug2 baz:slot iface disconnected,manual
foo:plug3 - non-auto -
$ snap connections -a foo
snap "foo" has 3 interfaces:
Plug Slot Interface Notes
foo:plug bar:slot iface -
foo:plug2 baz:slot iface disconnected,manual
foo:plug3 - non-auto -
I think I prefer the “before” version. And yes I’d also add a -d
flag (or --disconnected
if --all
instead of -a
) that would only list disconnected interfaces.
Lastly, in the -a
output I’d print the disconnected interfaces in dim.
HTH! HAND.
This was the original suggestion
why are we not doing that?
Fair point. Saves some typing when asking for a single snap.
What do you think about --disconnected
as suggested by @chipaca?
to use when? if the single snap prints everything? or to just list disconnected?
Right now I --disconnected
can be used with snap:
$ snap connections mutt
Plug Slot Interface Notes
mutt:network :network network -
$ snap connections mutt --all
Plug Slot Interface Notes
mutt:home :home home disconnected,manual
mutt:network :network network -
$ snap connections mutt --disconnected
Plug Slot Interface Notes
mutt:home :home home disconnected,manual
and without (this one gives a nice overview IMO):
$ snap connections --disconnected
Plug Slot Interface Notes
gitkraken:avahi-observe - avahi-observe -
gitkraken:camera - camera -
gitkraken:cups-control - cups-control -
gitkraken:home :home home disconnected,manual
mutt:home :home home disconnected,manual
test-snapd-daemon-notify:daemon-notify - daemon-notify -
- adapta-theme:adapta-gtk-theme content -
- gnome-calculator:gnome-calculator dbus -
- gtk-common-themes:gtk-2-themes content -
- lxd:lxd lxd -
Also something that came up while I was working on the output is I’m not showing unconnected core slots. There are just too mnany and listing all of them makes the output a bit overwhelming.
An update after discussions we had during the engineering sprint;
We’ve decided to drop --disconnected
, and keep --all
and querying explicitly by snap name.
Also some changes in the output were proposed.
View of a single snap:
$ snap connections wire
Plug Slot Interface Notes
wire:gtk-3-themes gtk-common-themes:gtk-3-themes content -
wire:icon-themes gtk-common-themes:icon-themes content -
wire:sound-themes gtk-common-themes2:sound-themes content -
$ snap connections gtk-common-themes
Plug Slot Interface Notes
wire:gtk-3-themes gtk-common-themes:gtk-3-themes content -
wire:icon-themes gtk-common-themes:icon-themes content -
wire:sound-themes gtk-common-themes:sound-themes content -
- gtk-common-themes:gtk-2-themes content -
Vanilla snap connections view:
$ snap connections
Plug Slot Interface Notes
wire:gtk-3-themes gtk-common-themes:gtk-3-themes content -
wire:icon-themes gtk-common-themes:icon-themes content -
wire:sound-themes gtk-common-themes2:sound-themes content -
mutt:home :home home -
mutt:network :network network -
icdiff:gitconfig :personal-files personal-files manual
icdiff:home :home home -
View of all connected and disconnected plugs & slots:
$ snap connections --all
Plug Slot Interface Notes
wire:gtk-3-themes gtk-common-themes:gtk-3-themes content -
wire:icon-themes gtk-common-themes:icon-themes content -
wire:sound-themes gtk-common-themes2:sound-themes content -
- gtk-common-themes:gtk-2-themes content -
test-snapd-daemon-notify:daemon-notify - daemon-notify -
mutt:home :home home -
mutt:network :network network -
mutt2:home - home -
icdiff:gitconfig :personal-files personal-files manual
icdiff:home :home home -
icdiff:removable-media - removable-media -
I’ve updated the PR accordingly.
It was proposed to move the Interfaces
column to the front, but no decision
was made. The output could look like this:
$ snap connections wire
Interface Plug Slot Notes
content wire:gtk-3-themes gtk-common-themes:gtk-3-themes -
content wire:icon-themes gtk-common-themes:icon-themes -
content wire:sound-themes gtk-common-themes2:sound-themes -
Looks like we have an agreement. The aggregate output shall look like this:
$ snap connections
Interface Plug Slot Notes
content[gtk-3-themes] wire:gtk-3-themes gtk-common-themes:gtk-3-themes -
content[icon-themes] wire:icon-themes gtk-common-themes:icon-themes -
content[sound-themes] wire:sound-themes gtk-common-themes2:sound-themes -
home icdiff:home :home -
home mutt:home :home -
network mutt:network :network -
personal-files icdiff:gitconfig :personal-files manual
Where the thing in [..]
next to the interface name is the value of a connection attribute that can was matched between plug and slot when the connection was established.
The relevant PRs have landed. The snap connections
command will be available in snapd 2.38. Alternatively, those running distros where snapd reexecs, can grab the core
snap from edge
channel.