How to "snap get" root document

pstolowski

#1

is there a reason (beyond a SMOP) that we don’t support snap get foo to get a dump of the config for foo, and instead require that the user knows the config keys to ask for?


Snap set digits as string
Make snap config discoverable
#2

The main reason we didn’t allow that upfront is to buy us time to get things right. The gut feeling at the time was that dumping a potentially large document on someone’s screen when the user doesn’t know what to ask for wasn’t very friendly. Now that we’ve experimented with it for some time, though, I would actually like to suggest a different behavior, which is much more friendly and also more consistent:

When asking for the root or any configuration options which are themselves set to a subdocument, we print nothing to standard output, and print a table with a “Key” header and a list of keys under it to stderr, with zero exit code. When listing subdocuments, the keys themselves should be a dotted path to the specific value, so that using any of them with the get command works.

To return a document or subdocument (root or otherwise), the -d needs to be passed explicitly, or multiple keys must be explicitly requested in the command line.

What do you think?


#3

One more related note here: it’d be great to have equivalent -t and -d options in the set side as well (snap and snapctl) with symmetric semantics: if -t is provided, only accept properly formatted JSON values. If -d is provided, only accept properly formatted documents.


#4

PR for the ‘snap get’ part of this story: https://github.com/snapcore/snapd/pull/3642


#5

@niemeyer, In the light of your review comments and the idea of showing {...} - given the following config:

{
  "a" : 1,
  "b  : {
    "c" : 2,
    "d" : 3
  }
}

would you only show:

Key   Value
a     1
b     {..}

Rather than:

Key   Value
a     1
b     {..}
b.c   2
b.d   3

?

I think the latter is more useful (it can be argued that {…} is redundant and uselsess in such case), as I think the original motivation was to make it easy to get all keys as otherwise they are hard to discover.


#6

Yes, the former with only a and b, assuming the get command was for the root document, except with 3 dots ({...}).

If one wants to know what’s under b, just run snap get mysnap b, and for the example it would then show:

Key   Value
b.c   2
b.d   3

Side note: the forum formatting needs three backticks for the block pre formating.


#7

As discussed in our stand-up yesterday, I also suggest changing the default behavior so that it prints the list if multiple keys are provided instead of a json document as done today. Since we’re not sure whether we’d be breaking people’s scripts by doing that, I suggest phasing the change in by first only showing the list if stdout is a terminal, and if it’s not a terminal printing the following warning to stderr:

WARNING: The output of “snap get” will become a list with columns - use -j to force JSON output.

To support that, let’s introduce two new flags right away: -j and -l (second one is an L), which enable forcing the output to be json or list no matter whether it’s a terminal or whether one, two, or more options were provided.

Comments?


#8

I’m slightly confused by -j, isn’t -d meant to do exactly that already (it forces json output)?


#9

You are right. They are the same thing indeed. I was thinking about -t which is different, and forgot about -d.


#10

The implementation of get has just landed in master. As discussed in the HO, there will be a follow-up branch to return empty document if no configuration exists for given snap. Also, the idea of -d and -t flags on the set side suggested above will be a dealt with separately.


#11

PR: https://github.com/snapcore/snapd/pull/3915