@robert.ancell, it’s complicated
First, I have questions: why in that feedback is there talk about a “snap dependency”? is this about integrating glib-snapd? Is that seen as worse than running
snap and parsing its output? How would that avoid things like the list of translations of interfaces, which
snap does not (and probably will not) have? How is a dependency on an abstraction around the snapd api worse than a dependency on parsing the commandline output of a different client of the same api? I mean, you could reimplement snapd-glib for
curl but it seems a little silly?
Second, while we do support the use of
snap from scripts and the like, including the ability to use it for asynchronous operations, we can almost guarantee it’s going to change over time (with announcements via the forum, and plenty of notice, and hopefully not willy-nilly), and worse the output of
snap info is still evolving. And while we do have designs for data extraction via a mini query language, and before that a simpler
--format flag, we won’t be able to implement either of these any time soon. And the example you gave, which is in the per-channel part of
snap info, we already know we’re going to be changing it soon (we consider it a freeform string right now, api-wise).