Determining the set of snapd capabilities

[Gustavo Niemeyer]

The intent of assumes features was to try not to overuse, because it
becomes hard to use and hard to maintain. The ideal candidate for a custom
entry on assumes are those features that can exist in one distribution but
not the other, due to constraints which are unrelated to it being merely an
old revision of snapd.

With that, it will get wild. Every other release of snapd has a new
feature, or multiple new features. It becomes unnecessarily messy to
maintain that list, and the output of "snap version" will also be wild.

Besides those custom entries, we also support a special entry for
snapd-proper, spelled as "snapd2.23" for example, This is only satisfied by
snapd 2.23 and newer, so it's a better mechanism to establish an ever
increasing number of features on snapd. Listing those would be extremely
boring, though, because it'd be a list like snapd2.15, snapd2.16,
snapd2.17, ... until the current version.

This latter mechanism was introduced later into the assumes system,
precisely because of the issues with the former approach. Instead of
encouraging more use of the former system, my suggestion is to continue
reserving it for the special cases, and focus documentation onto the latter.

I'd also avoid touching "snap version" for now, until we've explored the
system a bit further. We haven't added any new entries on the former
assumes system for a long while. We should probably deprecate the existing
entries there, until we have cross-environment differences to track (on the
same snapd version).


On Sun, Feb 19, 2017 at 8:21 AM, Mark Shuttleworth <mark at ubuntu.com> wrote:

>
> 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
>
>
>
> --
> Snapcraft mailing list
> Snapcraft at lists.snapcraft.io
> Modify settings or unsubscribe at: https://lists.ubuntu.com/
> mailman/listinfo/snapcraft
>



-- 

gustavo @ http://niemeyer.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20170220/bcd86f3e/attachment.html>