'snap find' does not allow channel specification

[Dmitrii Shcherbakov]

There is no option for 'snap find' to list snaps in a specific channel.

1) No such snaps
snap find ceilometer
The search "ceilometer" returned 0 snaps

2) However, it is present in the 'edge'
snap install --edge ceilometer
ceilometer 36.54 MB / 36.58 MB [===========================] 99.90% 4.24 MB/s 0

3) Help doesn't contain any related options:
snap find -h
Usage:
  snap [OPTIONS] find [find-OPTIONS] [<query>]

The find command queries the store for available packages.

Application Options:
      --version Print the version and exit

Help Options:
  -h, --help Show this help message

[find command options]
          --private Search private snaps
          --section= Restrict the search to a given section

I think it is worthwhile to add an ability to specify a channel, otherwise it is not really clear if a snap is present in the store or not.

[Mark Shuttleworth (sabdfl)]

This is something we discussed, and our current view (which can be
changed) is that snaps which have not yet made it to stable should not
be surfaced through general searches.

'snap info' should show you the details of a snap if you know it exists,
and the idea is that the developer or upstream can blog about a
non-stable snap and tell people the exact command to install (sudo snap
install foo --beta). Reading about a snap and installing it that way is
up to the user's discretion, but if we show snaps that are unstable in
snap find, then in a sense we are responsible for their installation of
unstable software, and we'd rather not do that.

So, for the moment, the policy is to encourage:

 * developers to blog about beta or candidate snaps to encourage testing
 * the 'find' results to reflect only snaps that have made it all the
way to 'stable'

Mark

[Dmitrii Shcherbakov (dmitriis)]

Mark,

Thank you for the clarification - I was not sure if it was deliberate or not.

I guess having `snap info` is enough as it provides a way to do a debugging query without performing an installation.

I would consider having `snap find` not return snaps from --edge while having an explicit option to include a specific channel which a regular user would not normally use. Having that would simplify searching in case you don't remember where the actual blog post page is or if a blog goes down. It doesn't seem to be a frequent use-case though might raise questions unless documented.

My intention was to check snap availability in any form.

Based on what I see this is a server-side limitation:

snap info ceilometer

sudo strace -s128 -f -p `pgrep -f snapd` |& grep -P 'connect|ceilometer'
[pid 20669] read(3, "GET /v2/find?name=ceilometer HTTP/1.1\r\nHost: localhost\r\nUser-Agent: Go-http-client/1.1\r\nAuthorization: Macaroon root=\"MDAxM2xvY2"..., 4096) = 257
[pid 20669] connect(4, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
[pid 20669] connect(5, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("127.0.0.1")}, 16) = 0
[pid 20669] connect(4, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("162.213.33.196")}, 16) = 0
[pid 20669] connect(4, {sa_family=AF_INET, sin_port=htons(9), sin_addr=inet_addr("162.213.33.200")}, 16) = 0
[pid 20669] connect(4, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("162.213.33.196")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 20669] stat("/snap/ceilometer/2/meta/gui", <unfinished ...>
[pid 20669] write(6, "<15>Feb 10 01:06:22 /usr/lib/snapd/snapd[3010]: daemon.go:176: DEBUG: uid=1000;@ GET /v2/find?name=ceilometer 508.671446ms 200\n", 127) = 127
[pid 20669] <... read resumed> "GET /v2/snaps/ceilometer HTTP/1.1\r\nHost: localhost\r\nUser-Agent: Go-http-client/1.1\r\nAuthorization: Macaroon root=\"MDAxM2xvY2F0aW"..., 4096) = 253
[pid 20669] write(6, "<15>Feb 10 01:06:22 /usr/lib/snapd/snapd[3010]: daemon.go:176: DEBUG: uid=1000;@ GET /v2/snaps/ceilometer 304.053\302\265s 404\n", 121 <unfinished ...>

nslookup 162.213.33.200
Server: 127.0.0.1
Address: 127.0.0.1#53

Non-authoritative answer:
200.33.213.162.in-addr.arpa name = search.apps.ubuntu.com.

[Mark Shuttleworth (sabdfl)]

I guess it might make sense to allow a user to specify --candidate,
--beta, or --edge and search the latest track up to that level of risk.
I.e. for --beta one would search stable, candidate and beta risk levels,
but not edge.

We'll hold to the current position for now, but that seems like a
reasonable alternative if we get a lot more non-technical user feedback
to this effect.

Mark

[Dimitri John Ledkov (xnox)]

Hello,

Please introduce --channel= and/or --candidate --beta -edge flags for the `find` command with same semantics as these flags for the `install` command.

Furthermore, I believe `info` command should act in the same manner, and default to stable channel only, and accept flags to show other channels info.

This is a grave usability bug for me.

Regards,

Dimitri.

[Mark Shuttleworth (sabdfl)]

I certainly think it's correct to not search non-stable channels without a very explicit user acknowledgement. I'm open to a --beta flag but I don't think it's a grave usability issue. We've taken lots of significant steps towards making it easier for folks to get to stable channels, and I think we want to keep social pressure on projects to get there.

'snap install foo --beta' already works, so for a community building towards a stable snap, there is plenty of opportunity for them to engage with their users through a beta or edge or candidate snap. 'snap find' is much more open-ended, and I think the current position of only finding stable snaps is correct.

[Zygmunt Krynicki (zyga)]

I'm marking this as triaged / wishlist. Please feel free to continue the discussion either here or on the snapcraft forum.