An update on the status of “wide” search results.
A prerequisite was having clearer messages when a snap is not found given the architecture/channel combination a user specifies (for commands like
snap install). The old message is low in details and looks like this:
error: snap "blahblah" not found in the given context. Please use 'snap info blahblah' to list available releases.
snapd 2.34 will have much improved messages:
error: snap "foo" is not available on latest/stable but is available to install
on the following tracks:
1.0/stable snap install --channel=1.0 foo
2.0/stable snap install --channel=2.0 foo
Please be mindful that different tracks may include different features.
Get more information with 'snap info foo'.
error: snap "foo" is not available on stable but is available to install on the
beta snap install --beta foo
edge snap install --edge foo
Please be mindful pre-release channels may include features not
completely tested or implemented. Get more information with 'snap info
And (this is a case we have actually seen, of people trying to install a snap not available for their architecture and scratching their heads as to why it’s not found):
error: snap "foo" is not available on stable for this architecture (arm64) but
exists on other architectures (amd64, s390x).
With these very informative messages in place (thanks @matiasb and @pedronis and Juan Real and if I forgot someone please let me know!), we now turn our attention to actually enabling search on non-stable channels/risks. This is ready to go on the snap store servers so at this point it’s a matter of snapd asking for those extended results (the server defaults to returning only “stable” channel results).
Keeping in mind that this will make
snap find return results for non-stable channels, thus exposing a much larger universe of snaps than before (a good thing!), the main thing to decide is whether the underlying snapd REST API will return these wide results by default. This means that all clients using the local REST API (CLI snap, gnome-software, Discover…) would magically start getting a lot more results, but it would also open the floodgates on possibly unsuspecting and unprepared clients and users. A possible issue here is how clients would surface snaps not on stable and how they query snapd to install those (where the error messages I posted above come into play).
The alternative would be for the REST API to need an additional parameter to enable wide searches (I’m thinking a parameter to https://github.com/snapcore/snapd/wiki/REST-API#get-v2find, as a whimsical strawman “
moarsnaps=yes”), which would require each client connecting to the API to pass this extra parameter in order to get extra results. The upside is that clients can control and decide whether to get wide results, and could even have a user-controllable switch (I’m assuming
snap, in a sense the client shipped with
snapd, would do this by default). The downside of course is that it implies extra work for the clients, and it means there might be a difference in results as the feature is implemented by them (hey why does Discover give me more snaps than gnome-software?).
What do you think?
- snapd REST API returns wide results by default, all clients start seeing those as soon as snapd enables this.
- snapd REST API returns only stable by default, needs an extra parameter to return wide results, clients need to ask for this explicitly.
- Something else I haven’t thought about