We’ve just rolled out a new version of the snap store, with some changes to how searching for snaps is implemented. Specifically, this new version contains improvements to our full-text search configuration, providing more relevant rankings of results to snap find, particularly for title matches. We’re pretty happy with the new results from snap find, but if you have any feedback on the relevance and ranking we’d be glad to hear it.
The API that the snap find command uses to find snaps allows callers to specify a “page size” that they want their search results to be paginated by. Anyone writing a client that uses the search API should be aware that when specifying the size query parameter, the store will do its best to satisfy that request but in some cases fewer results may be returned per page.
I’m finding it hard to find non-stable snaps, such as brave. And the ‘snap help’ just lists the find command without showing usage or listing more details help commands.
So while I know from word of mouth that ‘snap install brave --beta’ works, when I remove it and try to discover it more naturally with ‘snap find brave’ I don’t get anything. ‘snap help’ lists the find command superficially and ‘snap help find’ gives an error.
As someone has suggested to me, even mentioning that ‘beta channels do not get indexed by find. Please visit the respective application website for their installation method’ or something.
It has been general policy that snap find should only show snaps that are of high quality and ready for use by normal end-users. To that end, it only returns snaps that are in the stable channel. A number of people have asked for a flag to allow searching other channels (--channel= or --beta), and I think we will consider that option but we still wouldn’t expect most users to rely on it.
For now, snap info will give you more detailed information about any snap and show you which channels it is released into:
$ snap info brave
name: brave
summary: "Browse faster and safer with Brave."
publisher: brave
description: |
The new Brave browser automatically blocks ads and trackers, making it
faster and safer than your current browser. Start supporting publishers
today with our new Brave Payments system.
channels:
latest/beta: v0.17.13dev (3) 151MB -
latest/edge: v0.17.13dev (3) 151MB -
That post is good news, I was looking at the forum to start a discussion on the topic of results ranking. Is there any plan to sort the list to give more importance to the snaps which are more popular (having higher number of downloads for example)?
Currently we have basic facilities for manual curation of ‘featured’ snaps, which plays into search result ranking. We plan to improve that in the future with feedback from metrics and other sources.
Is it possible to return information on how the match occurred? In GNOME Software we have to blend results from different systems and this is done based on which data matched the search terms and how fuzzy it was.
We currently have the issue that we sort snap results before .debs but this means that a weak snap match (probably not useful) is above a strong .deb match, i.e.
strongest snap result
…
weakest snap result
strongest .deb result
…
weakest .deb result
It would be better to have
strongest snap result
strongest .deb result
…
weakest snap result
weakest .deb result
snapd provides an ordered list containing pretty much the same metadata as returned from locally installed snaps. It could be possible to re-scan the metadata for the search terms but this requires us to know some details about the algorithm used in the store (a problem if the algorithm changes in the future) and we can’t take into account any ordering based on non-metadata information (e.g. popularity as @seb128 suggested).
I’m hoping the store algorithm returns some rationale on why it returned results but I imagine it might not. Also not sure if the information is returned from the store and just needs passing through snapd.
@noise - I’ve come up against this again in GNOME Software where the lack of ordering information was causing our results to get messed up. Internally GNOME Software uses a 0-100 value to decide how “good” a match is. Is there anything like this the store could easily return?
Yeah, best-to-worst seems pretty reasonable, and doesn’t feel worse than 1-100 if there’s no clear indication of what the numbers mean. Perhaps the numbers would give the client a slightly better chance of cutting off results which are too bad, but that should really be happening in the server end instead of expecting every client to take that sort of decision. So not even clear if we do want to expose “how good” a match is.
For the edge/beta changes, just for clarity, there are no actual changes in the API, right?
We will need to make API changes to support surfacing other channels in search as we will at least need to indicate the channel information. Or at least my assumption was that we’d augment the output, we can cover that in the other thread and/or sync up next week.
