snap list/find output

Tue May 24 16:40:20 UTC 2016

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/snapcraft/attachments/20160524/64bfbbe0/attachment.html>