Showing edge and beta in search results

store
1

Hello all,

I’m pretty sure we talked about this before, but I cannot find a good reference to the agreement, so here is it again just in case.

In the recent sprint we’ve discussed the fact that a snap does not show in search results unless there is a revision in candidate or stable. The conclusion was that we want to lift that restriction, on the following basis:

  • There are actual snaps in use that people know about and yet they can’t find it for no clear reason.
  • Some software remains in beta or alpha for a long time, yet people use it widely.
  • The results constraint creates pressure towards mislabeling the software just so people can find it.
  • One cannot install from edge or beta without specifically saying so.

With all that said, @jdstrand later raised an interesting point about whether the devmode flag should affect results, and I think it should in the cases where the only snaps available require devmode, because it’s awkward to offer something to actual users while it can only possibly run in development mode.

So given these conversations, there’s some agreement about changing the filtering towards the rule:

Snaps are displayed in search results as long as there is at least one revision currently available that does not depend on devmode.

Sounds reasonable?

2 Likes
2

This sounds reasonable to me. My main concern was promoting snaps that use --devmode since they run unconfined.

I do wonder about the UX and what the implementation will do in cases like: r1 is devmode, r2 is strict, r3 is devmode, r1 candidate, r2 beta and r3 edge. Will only r2 be shown?

What if r1 is devmode, r2 strict, both in edge. Presumably snap find would show r2. What if r3 is devmode and uploaded to edge. Does snap find now not show it?

(These are not blockers to the general idea, just curious on the details).

1 Like
3

If we go with the logic described above, if there is at least one revision published which is not devmode, we should show the snap in search results. The devmode snaps can only be in edge or beta, so to install a devmode snap people have to explicitly say --devmode, and --channel=…, which means there’s plenty of hints about what is being done. The reason to not show the snap when there are only devmode snaps published is not because it’s dangerous, but because it feels awkward to recommend to people something that can only be installed in development mode, supposedly useful for developers of the snap mainly.

1 Like
4

Whenever you do something to reduce false negatives, you need to be careful about how much you increase false positives. (And vice versa.)

Here the false negative you are fixing is, “Snap X exists and is useful, but it isn’t showing up in search results and should be”. The corresponding false positive is, “Snap Y is unready or experimental, so I don’t want it showing up in search results, but it is”.

Recently we tested a prototype Snapcraft site that guided people to getting their first snap released to edge for initial testing, leaving out all non-compulsory steps — on the assumption that if we get people to that achievement, things like adding screenshots, categories, and prices can be handled afterwards, before promoting to beta/candidate/stable.

That could be a problem if edge snaps show up in search results. The most common issue would be the number of hello-world-type test snaps in the store. A more serious example would be if a vendor was intending to make a cross-platform release announcement, that would be spoiled if people encounter the snap in a search before it’s ready.

So here’s a question that may (I hope!) have a very simple answer: If edge is searchable, then where should someone’s initial snap go — so that the publisher can test that the store works, but not have the snap show up in searches? Is it:

  • pushing but not releasing?
  • new snaps being private by default?
  • something else?
5

We’ve been telling vendors to push as many revisions as they’d like to the Snap Store, but not release into a channel until they are ready to make a public announcement.

If you release into edge today, you still risk people guessing at what might be available.

6

This is a great idea. May I propose we also update how snap install works when you ask for a snap only available in a non-stable channel?

Left as is, it would not guide the end user to resolution:

$ sudo snap install gradio-ev
error: snap "gradio-ev" not found

What do we think of something like this:

$ sudo snap install gradio-ev
error: snap "gradio-ev" is not available from the stable channel.

       It can be installed from the edge channel (with associated risks):
       snap install --edge gradio-ev
2 Likes
7

Agreed, we need to improve the message on those errors. We also need to handle independent architectures, and we should show every architecture on find too. It’s too confusing nowadays to have two x86 systems and not be able to find a snap in one of them but in the other. It should be listed on both, and install on the unsupported architecture should explicitly say why that’s not working instead of saying “not found”.

8

As a minor, I’d prefer to not spell out instructions for every channel, even because it will get wild in quite typical cases. Instead, let’s recommend something like (see snap info <snap>) so they get the channel map.

9

This conversation is relevant here:

10

Hello folks!

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'.

And:

error: snap "foo" is not available on stable but is available to install on the
       following channels:
       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
       foo'.

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?

  1. snapd REST API returns wide results by default, all clients start seeing those as soon as snapd enables this.
  2. snapd REST API returns only stable by default, needs an extra parameter to return wide results, clients need to ask for this explicitly.
  3. Something else I haven’t thought about :slight_smile:
  • Daniel
11

@chipaca opened this:

12

That change will be part of the 2.34 release.

13

Great! well this means clients will not have to do anything to benefit from this. (edited per Samuele’s reply below). Great! well, this means people using snap find in the command line get wide results now. Does this mean, then, that we’ve decided to keep narrow searches as the snapd default and clients will have to “opt in” by passing the parameter?

Also the parameter to snapd’s /v2/find to return non-stable snaps is scope=wide, right? (glad we went with that and not my silly proposal :slight_smile:

Thanks!

14

no, the default is for snap find, on the snapd API narrow/stable-only is still the default

15

yes, as it’s a potentially breaking change

correct, scope is passed straight through to the store

16

Fantastic! I do think it’s the right way to do it, hopefully I didn’t bias too much that way in my original post. Thanks!

Should we invoke people working on gnome-software and KDE Discover to let them know about this and help get it implemented across the fleet of clients?

  • Daniel
17

What are the supported scope values? I will add flags to the snapd-glib API for each supported scope.

18

scope=wide will show you beta and edge results, omitting it will restrict your results to stable only.

19

scope=wide also gives results from candidate. This includes only the latest track however.

20

snapd-glib MP: