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