From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: User-Friendlyness of Guix and non-scaryness, printing messages Date: Sun, 28 May 2017 23:12:44 +0200 Message-ID: <878tlgn0s3.fsf@gnu.org> References: <87bbe3e5.AEAAKL2r-KIAAAAAAAAAAAOtUOAAAAACwQwAAAAAAAW9WABZGcQo@mailjet.com> <87y3tw4kw3.fsf@gnu.org> <87r2zfx0xt.fsf@gnu.org> <427678e8.AEUAKjfDcSgAAAAAAAAAAAPB0agAAAACwQwAAAAAAAW9WABZKceD@mailjet.com> <20170528204437.6dfd35c4@scratchpost.org> <20170528192058.GF15883@jasmine> <20170528214029.58dafacf@scratchpost.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33296) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dF5UZ-00087x-Ay for guix-devel@gnu.org; Sun, 28 May 2017 17:12:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dF5UW-0000Vl-5g for guix-devel@gnu.org; Sun, 28 May 2017 17:12:51 -0400 In-Reply-To: <20170528214029.58dafacf@scratchpost.org> (Danny Milosavljevic's message of "Sun, 28 May 2017 21:40:29 +0200") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Danny Milosavljevic Cc: guix-devel@gnu.org Hello, Danny Milosavljevic 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=E2=80=99ve just pushed an old experiment as =E2=80=98wip-ui=E2=80=99 to g= ive an idea of what I mean. If it still works, =E2=80=98guix package=E2=80=99 shows N line about= the ongoing progress, where N is the number of parallel jobs (--max-jobs). It could be as concise as this: . The easiest way to do that is to =E2=80=9Cparse=E2=80=9D what goes to =E2=80=98current-build-output-port=E2=80=99 and to filter and format the re= levant info in the client. =E2=80=98wip-ui=E2=80=99 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=E2=80=99s easy because we can print things sequentia= lly, 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=E2=80=99d need to use ANSI codes to erase the previous lines and write t= he updated lines. However, this wouldn=E2=80=99t work with dumb terminals (li= ke shell-mode :-)) so we=E2=80=99d 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=E2=80=99.