Determining the set of snapd capabilities

[Mark Shuttleworth]

We have a nice mechanism to ensure that snaps which use newer
capabilities don't end up on systems with older snapd's that don't
support those capabilities, which is the 'assumes' keyword. This email
is a proposal to make that usable.

The mechanism is mentioned in the snapcraft docs at
https://github.com/snapcore/snapcraft/blob/master/docs/snapcraft-syntax.md
which is published at https://snapcraft.io/docs/build-snaps/syntax but
not clarified anywhere else that I can see. I have been unable to find a
list of the available capabilities that can be assumed. Whatever else is
true, the fact that I couldn't find it despite the help of the AIs at
Google suggests that we can improve the discoverability and usefulness
of this potentially very useful capability :)


Step 1, show what capabilities a snapd offers.
https://bugs.launchpad.net/snapd/+bug/1665995

'snap --version' is a nice way to know what versions are relevant for a
particular system. That would be a good place to show the capabilities
that can be assume'd for snaps being installed on that system. It
doesn't require a new command and it is in many ways more relevant to
developers than the particular version. At least, the intent of
capabilities is to have fewer version-specific dependencies, and more
capability-specific dependencies!


Step 2, reference 'snap version' in the docs

The existing docs for snapcraft.yaml and snap.yaml should both make
clear reference to 'snap version' as a way to discover these
capabilities. Also, there should be express documentation on each of
them, organized as such. So the docs should say "use 'snap version' to
see what a particular system supports, and see <URL> for documentation
about each of those capabilities". That documentation should explain any
constraints or usage of the capabilities.


Step 3, introduce capabilities as 'beta-capability'

When we land new features, there are often rough edges. For example,
there is a new capability to support direct setting of environment
variables in snap.yaml which is super useful (many snaps have wrappers
just to do this, so that's one less layer needed in the common case :)).
However, there is a bug in the implementation which means you sometimes
get a newline on the environment variable, which is unhelpful. I think
this should be a beta-capability till we know it is fully fleshed out.


Step 4, announce new capabilities on the list

In many cases, the existence of a new capability is meaningful for a
large number of snapcrafters, lets share the beta documentation on the
list when the capability lands in a --proposed or --candidate release of
snapd+snapcraft.


Step 5, nobody expects the Spanish Inquisition.


Mark