"snap info" channel map format

[chipaca]

The output of snapcraft status foo (and of snapcraft release foo) includes something that’s been colloquially called a “channel map”, which looks like

Track    Arch    Channel    Version    Revision
latest   all     stable     -          -
                 candidate  1.0        5
                 beta       ^          ^
                 edge       1.0+fake1  5

just in case it isn’t clear from the output, a - means the channel is closed and you can’t interact with it, and a ^ means the channel is closed and request for things from that channel will come from a more stable channel that is not closed. From the store AIUI the former is a “closed” channel, the latter is “tracking” (but I might’ve gotten this wrong).

When implementing snap info, as with other such features, we tried to keep the “channel map” as close to the snapcraft status output as was reasonable, and this included the - and ^s.

However in lp:1628640 @sabdfl says “please do show it as closed, explicitly, if its closed.”, which @facundobatista takes to mean it should actually say closed, not - nor ^ (but I’d argue that - / ^ is explicitly saying it’s closed; not being explicit would just print the version, as we were doing before we had channel_maps_list in the JSON).

Unsure which is the right approach (even though I favour the -/^ one, in case it wasn’t clear above ).

(this all came up because we have a bug in snap info right now , with it not showing closed channels at all – which is also “explicit”… but I’m fairly certain this is not what we want).

[niemeyer]

We’ve discussed this extensively in the Vancouver marathon where we defined most of the user experience around channels and those commands, and indeed the agreement is to have ^ rather than closed, and this still sounds like a much better option in terms of it being cleaner and that it makes more explicit the fact there’s a fallback. Let’s please not change it.

If @sabdfl disagrees with the status quo which is based in the Vancouver agreements, we need to at least have a proper conversation about it before it’s changed, rather than just a note in Launchpad. @Chipaca, can you please ensure we’re not breaking the current format before that takes place?

As a side note, let’s please stop using the term “tracking” for the fallback behavior, even if that was originally agreed there. Follow up agreements means we’re now using the term “tracks” with a conflicting meaning.

[chipaca]

https://github.com/snapcore/snapd/pull/3286 addresses the issues, and is a string change away from the actual “closed” version of things if wanted.