Snaps unavailable for your architecture are effectively reported as not existing at all

Ideally the store would provide the required information. We get currently:
"""
$ http --pretty=format --print b https://api.snapcraft.io/api/v1/snaps/details/robotfindskitten X-Ubuntu-Architecture:arm64 X-Ubuntu-Series:16 fields==anon_download_url,architecture,channel,download_sha3_384,summary,description,binary_filesize,download_url,icon_url,last_updated,license,package_name,prices,publisher,ratings_average,revision,screenshot_urls,snap_id,support_url,title,content,version,origin,developer_id,private,confinement channel==edge
{
    "error_list": [
        {
            "code": "resource-not-found",
            "message": "Snap 'robotfindskitten' (CDwOz6O4zGyVXLcHbxWx9K7XTGmZCBye) has no published revisions in the given context."
        }
    ],
    "errors": [
        "Snap 'robotfindskitten' (CDwOz6O4zGyVXLcHbxWx9K7XTGmZCBye) has no published revisions in the given context."
    ],
    "result": "error"
}

"""

As a workaround we do it with the current store responses. Then we would have to do an additional http request that omits "X-Ubuntu-Architecture" after each 404. If this extra request did not give us a 404 we can print the nicer error message. But it would be preferable to have this from the store directly.

Omiting architecture makes it default to amd64 afaik; you'd need to know the list of architectures of the store you're querying, and loop

$ uname -i
x86_64
ubuntu@bionic-snap:~$ snap install pi-kernel
error: snap "pi-kernel" is not available on this architecture (amd64) but exists on other
       architectures (arm64, armhf).

Note I had to know the name of the snap in advance; snapd does send the architecture header which restricts what gets returned by snap find or snap info.

I marked the store task as fix released, but I believe the snapd tasks can be marked as such as well.

While "snap install" appears fixed, "snap find" and "snap info" probably need some work still. For instance, "snap info pi" to get information about the pi gadget snap returns useful info on a Pi, but on a PC returns:

$ snap info pi
error: no snap found for "pi"

Likewise, trying to find the libreoffice snap on a Pi returns:

$ snap find libreoffice
No matching snaps for "libreoffice"

The latter in particular is likely to be the first thing users try before installation, and the error message heavily implies there's no such snap. The new installation error message would be much more useful here.

Hi Dave!

"snap find" has an architecture parameter which snapd is likely setting to the value of the invoking system's architecture. I question the value of extending the API to search in architectures other than the one we were given - perhaps snap should say "no snap found for 'blah' on architecture 'whatever'" to clarify the search parameters that were used, and point to the possibility it exists in other architectures but I wouldn't go further than that.

Likewise, "info" supports an architecture parameter; here, actually, if it's not given we do return all the information for the snap. If it is given, the API still returns something:

$ curl "https://api.snapcraft.io/v2/snaps/info/pi?architecture=amd64" -s -H "Snap-Device-Series: 16" -H "Snap-Device-Architecture: amd64" | jq .
{
  "channel-map": [],
  "default-track": null,
  "name": "pi",
  "snap": {
    "license": "unset",
    "name": "pi",
    "prices": {},
    "publisher": {
      "display-name": "Canonical",
      "id": "canonical",
      "username": "canonical",
      "validation": "verified"
    },
    "snap-id": "YbGa9O3dAXl88YLI6Y1bGG74pwBxZyKg",
    "store-url": "https://snapcraft.io/pi",
    "summary": "Raspberry Pi gadget",
    "title": "pi"
  },
  "snap-id": "YbGa9O3dAXl88YLI6Y1bGG74pwBxZyKg"
}

In the "info" case it seems snapd could say "this snap exists but not for this architecture" (actually if I don't filter by architecture I do get the entire channelmap and from there snapd could plausibly say "not available for this architecture but available for these other ones") though again I am unsure of the value - if a snap I'm interested in is available only for s390, I'm not about to go buy a mainframe so I can run it :).

A possible fallback would be to tell the user to visit the snap's page on the web; supported architectures are clearly indicated there:

https://snapcraft.io/libreoffice

I think API support to enhance this is present in the snap store, so I'll leave the store task as fix released. I also remember we have discussed this at length with Gustavo and other stewards of the snap ecosystem, it's probably fair to point out the imperfect user experience in the cases you mentioned but a change needs to be discussed with other stakeholders as well.

> I question the value of extending the API to search in architectures
> other than the one we were given - perhaps snap should say "no snap
> found for 'blah' on architecture 'whatever'" to clarify the search
> parameters that were used, and point to the possibility it exists in
> other architectures but I wouldn't go further than that.

The current behaviour of snap find means that, currently on the Ubuntu Desktop for Raspberry Pi, your average user looking for snaps encounters the following:

"I want to code something"

$ snap find pycharm
No matching snaps for "pycharm"
$ snap find intellij
Name Version Publisher Notes Summary
gradle 7.2 snapcrafters classic An open-source build automation tool
$ snap find code
... a page+ of output, none of which is VS Code ...

I appreciate that telling the user a snap exists, but not for their architecture, really doesn't help that user in any immediate sense. However, making the user wade through a page of results, none of which is relevant, actively wastes the user's time compared to just telling them "yes, the snap you're looking for exists ... but the developer hasn't built it for your machine".

Just to give a little clarification of the origin of this request, it's related to https://github.com/canonical-web-and-design/snapcraft.io/issues/3969. And yes, I'm (probably naïvely) hoping that a few hundred pitch-fork wielding users might motivate the odd upstream to build for more than just the PC :)