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?
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?
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.
@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.
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.
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?
I’m slightly confused by -j, isn’t -d meant to do exactly that already (it forces json output)?
You are right. They are the same thing indeed. I was thinking about -t which is different, and forgot about -d.
1 Like
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.
1 Like