to do such things you would have to use the snapd REST API (https://github.com/snapcore/snapd/wiki/REST-API) but to use this from a snap you need to use the snapd-control interface which restricts your snap package to only be allowed in brand stores, not in the global store …
From a quick look, I guess the snapd rest api needs login and password of an account and can control the other app of the system.
Since we don’t want to control other apps, nor forcing a login, this brings me to the question is there no way (currently or planned) for a snap to trigger itself (through snapctl, environment var, or other means) one of these actions ?
it is the REST API equivalent of the snap command you’d use on the command line and has all its capabilities, while snapctl only has a limited set of features (config settings, start/stop services from inside a snap, checking if interfaces are connected) …
(and indeed, on the commandline you also need to either be logged in or use sudo for using most of the snap commands (beyond basic informational bits like “find” and … well … “info” )
right, this would have to be added, snapctl is limited to the above few features atm.
what’s the actual use case? the snap can carry version information and act on that
yes, this is in our upcoming list to implement
yes, likely, involving though some form of user confirmation external to the app
maybe, again it would need to involve some form of user confirmation external to the app. Is the use case here more switching risks or switching tracks?
Simply being able to display on the app the current tracks/risk. The best would be through environment variable, so I can display on my app SNAP_REVISION and hopefully SNAP_CHANNEL SNAP_TRACKS or other, which is not available for now right ?
Yes that would be great, actually for our use case already being able to trigger a snap refresh but from the app itself (through snapctl for example) would be nice
Actually our app is a daemon only accessible through a web interface, so if there is a user confirmation it should be something handled with code in our use case.
I can understand giving the ability from an app to switch its own track can lead to some debate, but I think that changing risk, i.e. edge/beta/candidate/stable might be something that the snap itself should be able to do. My use case is just providing the user the choice to change risk of the app, and hopefully to display current risk and optionally track. This way the user can opt-in to be more closer to the edge to for example temporally test more recent and risky features, or switch back to candidate or stable, from the app interface.
Oh yes I forgot to mention, the whole concept of these snapctl additionnal features suggestion is to be able to trigger from a snap itself, not externally, so affecting only the snap using the command.
If they are making sense and should lead to a discussion should I post a more complete suggestions request somewhere in the forum ?
yes, something along those lines will happen in one of the next releases of snapd. Likely via snapctl, not env vars.
that’s an area that will be explored soon, but as I mentioned before not in a way that let’s a snap just refresh itself. I expect something like that with user feedback is more of a medium term thing.