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 <[email protected]> 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 > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/snapcraft > -- gustavo @ http://niemeyer.net
-- Snapcraft mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
