snap list/find output

Wed May 25 08:43:35 UTC 2016

With your suggestion for "snap find" output, even with the paltry
packages we have today, you already have just three characters left
before the 80th column for summary, and a third of that width is used
up for "version". That seems wrong to me, and it's only going to get
worse as "Notes" gets used.

"snap list" would hit similar issues as well.

On 24 May 2016 at 17:40, Gustavo Niemeyer
<gustavo.niemeyer at canonical.com> wrote:
> Thanks for putting these ideas together, John.
>
> So, some preliminary thoughts:
>
> - We don't need to have list and find output with the same format; they're
> oriented towards different problems (finding what to install, vs. listing
> what is installed), so we can optimize their output for these problems.
>
> - Not every single detail about a snap should be present in the output for
> these commands. This is obvious, but also too easy to unintentionally get
> wrong.
>
> - Some of the mentioned flags are system-level settings (tainting, reboot
> required, etc). These should not be in find or list.
>
> - It's okay to shorten fields which are likely too long (summary), but
> doesn't seem okay to shorten core fields such as version.
>
> - Having "see info" for data that sometimes is there and sometimes not seems
> a bit strange. I'd prefer to draw a line about what is there or not so it
> doesn't get out of hand, but trust these details defined to always be there.
>
> - Revisions can be x1 for local revisions, so we the "r" prefix doesn't look
> so great here or anywhere else. Having it space-separated from the version
> also feels slightly awkward because it breaks the obvious parsing (N columns
> == A+1+B fields).
>
> On that basis, here is a concrete proposal:
>
> https://gist.github.com/niemeyer/22c0c8619456a9494396bc3af6ff1891
>
> The notes presented there are the only details I'd show as the output of
> these commands. Other data would be presented elsewhere.
>
>
>
> On Tue, May 24, 2016 at 1:03 PM, John Lenton <john.lenton at canonical.com>
> wrote:
>>
>> As we add richer options to snaps and want to rightly expose them in
>> the commandline output, the question is how to make it usable.
>>
>> The output of `snap list`, for example, needs to show, in a single
>> line that could reasonably be as narrow as 80 columns wide:
>>
>> some are text fields, with reasonably long limits (e.g. 32 chars for
>> version):
>>
>> name
>> version
>> revision
>> developer name, at least if different from publisher name
>> summary
>>
>>
>>
>> (when querying the store we could also have "price" for example)
>>
>> and some that are flagish:
>>
>> is it private?
>> is it devmode?
>> try?
>> has it been paid for?
>> does it provide services, and are they running ok?
>> does it have updates available?
>> is the revision we're on "pinned" because of it being manually requested?
>> it has updates available, and we're not going there because
>> ...they're devmode and we aren't? [this might be invisible to the client]
>> ...we tried and had to rollback?
>> ...rollback was done by user?
>>
>> there's also some system-level things we want to output on snap list:
>>
>> is a reboot required?
>> is it a devmode-only thing? (e.g. running without apparmor in the kernel)
>> is the system tainted or otherwise dirty? (nothing done for this yet,
>> but needs thinking aboot)
>>
>> i'm also probably forgetting things.
>>
>> One thing I *don't* want us to do is have something like the header on
>> `dpkg -l`:
>>
>> Desired=Unknown/Install/Remove/Purge/Hold
>> |
>> Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
>> |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
>> ||/ Name           Version      Architecture Description
>>
>> +++-==============-============-============-=================================
>>
>> I also don't want us to punt on the problem by not exposing this info
>> and having a `-o` option à la ps; the defaults should be good enough
>> (especially given that the REST API is straightforward enough if
>> developers need more control) (not to say that we don't add something
>> like -o down the line, but it's cornercase).
>>
>> So, having said all this, I think we can get very good results by
>> using adaptive layout with a combination of colours, a bit of unicode,
>> and per-column shortening strategies.
>>
>> A lot of this working hinges on there being a clear precedence in the
>> "flagish" columns. For example,
>>
>> First off, if the output isn't a tty, just output tab-separated
>> non-shortened columns. Easy for programs to poke at. Otherwise:
>>
>> Never shorten name nor revision. If just those two don't fit, tough
>> luck. But don't use a header for Revision (as most often that will be
>> wider than the revision); just r%d (after version, if it fit).
>> Put all flagish things under a single (e.g.) "Notes" column. If a ",
>> "-separated list of the most succint way of describing each flag
>> doesn't fit, put "see info" (or e.g. "info" if that works). Assume
>> you've shortened it for now. Colourize the line based on what's in the
>> notes (e.g. red if it demands attention). Maybe also add an
>> exclamation mark if it does!
>> If you're already at the width, that's it. Otherwise, while each bit
>> of info doesn't go over the width,
>> Shorten version down to the localised length of "Version", using an
>> ellipsis (… U+2026 HORIZONTAL ELLIPSIS) in the middle.
>> Shorten developer name down to the localized length of "Developer",
>> with an ellipsis at the end.
>> Add summary, ellipsised at the end.
>> Go back and lengthen "notes" if possible.
>>
>> that, to my mind, works.
>>
>> I can implement a PoC of this so we can play with it if you'd rather,
>> but I didn't want to dive into doing that first before we checked
>> whether I was sane.
>>
>> Anyway. Bikeshed away!
>>
>> --
>> Snapcraft mailing list
>> Snapcraft at lists.ubuntu.com
>> Modify settings or unsubscribe at:
>> https://lists.ubuntu.com/mailman/listinfo/snapcraft
>
>
>
>
> --
> gustavo @ http://niemeyer.net