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
