Re: User-Friendlyness of Guix and non-scaryness, printing messages

[Ludovic Courtès]

Hello,

Danny Milosavljevic <address@hidden> skribis:

>> Perhaps for `guix package`, but I disagree for `guix build` and others.
>> It prints *only* the new store items on stdout, and this makes it very
>> easy to compose Guix commands. We should not break this.
>
> I agree. guix build is different.  Its whole point is to do that.
>
> The scripts I mean are:
> - guix package
> - guix system

Agreed for these.

Danny, your suggestions go a bit further than what I had in mind :-),
which was to write (roughly) one progress line per item built or
downloaded.

I’ve just pushed an old experiment as ‘wip-ui’ to give an idea of what I
mean.  If it still works, ‘guix package’ shows N line about the ongoing
progress, where N is the number of parallel jobs (--max-jobs).  It could
be as concise as this:
<http://nim-lang.org/news/e029_version_0_16_0.html>.

The easiest way to do that is to “parse” what goes to
‘current-build-output-port’ and to filter and format the relevant info
in the client.  ‘wip-ui’ is a very first stab at this.  The new (guix
status) module maintains a representation of the on-going builds and
downloads, which can be used by the UI.

When max-jobs is 1, it’s easy because we can print things sequentially,
and the patch does that well (modulo cosmetic improvements that can be
made).

But what should be the UI when max-jobs is greater than 1?  I was
thinking that if there are, say, 2 builds and 2 downloads in parallel,
we could display 4 lines, one for each of these.  Thus at each refresh,
we’d need to use ANSI codes to erase the previous lines and write the
updated lines.  However, this wouldn’t work with dumb terminals (like
shell-mode :-)) so we’d probably need a fallback mode.

Anyway, food for thought.  We should also come up with more mockups of
the ideal thing, or pointers to screenshots of existing UIs.

Also, parsing the build logs like this branch does is far from ideal.
We might need to rework the daemon protocol to have more structured
messages, and better routing/labeling of build logs.

Thanks,
Ludo’.