Parsing snap info

snapd
1

When I run snap info juju

I get the following in channels:

channels:                                                                      
  stable:    2.2.4                      (2529) 25MB classic                    
  candidate: 2.2.5+2.2-c1f373c          (2623) 43MB classic                    
  beta:      ↑                                                                 
  edge:      2.3-alpha1+develop-3fd2bbf (2625) 51MB classic

That is good in terms of a user perspective, but I have no easy way to read this information programatically.

Previously I have been loading this output as yaml to parse it, but it is hard to define the correct semantics for “↑”

I can sort them and fall back, which is what I guess I will be doing. Anybody else doing similar or a desire for this code to be somewhere more helpful?

2

Hitting the snapd API directly might give you better results, e.g.:

$ curl -s --unix-socket /run/snapd.socket http:/v2/find?name=juju | jq
{
  "type": "sync",
  "status-code": 200,
  "status": "OK",
  "result": [
    {
      "channel": "edge",
      "channels": {
        "latest/candidate": {
          "revision": "2623",
          "confinement": "classic",
          "version": "2.2.5+2.2-c1f373c",
          "channel": "candidate",
          "epoch": "0",
          "size": 43294720
        },
        "latest/edge": {
          "revision": "2625",
          "confinement": "classic",
          "version": "2.3-alpha1+develop-3fd2bbf",
          "channel": "edge",
          "epoch": "0",
          "size": 51953664
        },
        "latest/stable": {
          "revision": "2529",
          "confinement": "classic",
          "version": "2.2.4",
          "channel": "stable",
          "epoch": "0",
          "size": 25292800
        },
        "latest/stable/jpmc": {
          "revision": "2514",
          "confinement": "classic",
          "version": "2.2.3+secgroups+cidr",
          "channel": "stable/jpmc",
          "epoch": "0",
          "size": 25296896
        }
      },
      "confinement": "classic",
      "contact": "http://jujucharms.com",
      "description": "Through the use of charms, juju provides you with shareable, re-usable, and repeatable expressions of devops best practices.",
      "developer": "canonical",
      "download-size": 51953664,
      "icon": "",
      "id": "e2CPHpB1fUxcKtCyJTsm5t3hN9axJ0yj",
      "name": "juju",
      "private": false,
      "resource": "/v2/find?name=juju",
      "revision": "2625",
      "status": "available",
      "summary": "juju client",
      "title": "juju",
      "tracks": [
        "latest"
      ],
      "type": "app",
      "version": "2.3-alpha1+develop-3fd2bbf"
    }
  ],
  "sources": [
    "store"
  ],
  "suggested-currency": "USD"
}
3

super cool, I did not know about the snapd API!

lutostag@doe:~$ curl -s --unix-socket /run/snapd.socket http://localhost/v2/find?name=juju | jq '.result[].channels' 
{
  "latest/candidate": {
    "revision": "2623",
    "confinement": "classic",
    "version": "2.2.5+2.2-c1f373c",
    "channel": "candidate",
    "epoch": "0",
    "size": 43294720
  },
  "latest/edge": {
    "revision": "2628",
    "confinement": "classic",
    "version": "2.3-beta1+develop-97fbe8f",
    "channel": "edge",
    "epoch": "0",
    "size": 52006912
  },
  "latest/stable": {
    "revision": "2529",
    "confinement": "classic",
    "version": "2.2.4",
    "channel": "stable",
    "epoch": "0",
    "size": 25292800
  },
  "latest/stable/jpmc": {
    "revision": "2514",
    "confinement": "classic",
    "version": "2.2.3+secgroups+cidr",
    "channel": "stable/jpmc",
    "epoch": "0",
    "size": 25296896
  }
}

(with curl >7.50 you need to use localhost btw https://superuser.com/a/925610)

Still I need to have my parser understand the ordering that if there is no beta to instead use the “more stable” candidate – if that channel even actually exists.

Seems like the ordering is implicit. And that is fine, just don’t want to have to replicate the logic if I can get at it a different way.

But either way, definitely something I can work with.

Thanks!

4

@lutostag The order is implicit in those cases indeed. Whenever a channel is closed, either because it never got anything released on it or because it was explicitly closed afterwards via snapcraft close, installs and refreshes will fallback to the channel that would offer less risk, potentially jumping through multiple channels.

The order is the one implied in the command output:

  • edge → beta → candidate → stable

The arrow pointing upwards in the info output hints at that behavior.

There are other details surrounding channel terminology in the documentation.