From mboxrd@z Thu Jan 1 00:00:00 1970 From: Danny Milosavljevic Subject: Re: User-Friendlyness of Guix and non-scaryness, printing messages Date: Sun, 28 May 2017 21:40:29 +0200 Message-ID: <20170528214029.58dafacf@scratchpost.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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:47204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dF43J-0000y7-Gn for guix-devel@gnu.org; Sun, 28 May 2017 15:40:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dF43F-0002GM-In for guix-devel@gnu.org; Sun, 28 May 2017 15:40:37 -0400 Received: from dd1012.kasserver.com ([85.13.128.8]:40092) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dF43F-0002G5-BZ for guix-devel@gnu.org; Sun, 28 May 2017 15:40:33 -0400 In-Reply-To: <20170528192058.GF15883@jasmine> 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: Leo Famulari Cc: guix-devel@gnu.org Hi Leo, On Sun, 28 May 2017 15:20:58 -0400 Leo Famulari wrote: > This sample omits the most useful output, which is the summary of what > will be done. That's because even my huge xterm scrollback buffer doesn't contain it anymore. I couldn't include it because I never saw it in the first place - and I can't reach it anymore. > 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 > Command-line interfaces are not suitable for usage by "non-technical > users" anyways; they demand a GUI. Yes, but these were technical users - the deepest technical users, too. Previously, I thought that the reason that guix prints so much is that it doesn't log it to a file. But it turns out that it does log it (at least it has a build log per derivation), also in the failure case. Why print it then when there's no failure? It doesn't help the user at all. He's not gonna frame the output and hang it on a wall :) For the failure case, he can just be directed to the build log (by the failing command!) - if he or a developer wants to know, he can check it. > So, I'm wary of sacrificing a flexible and powerful CLI on behalf of > users who really will never use a CLI. Now, I'm not saying there is > nothing to improve. Rather, I'm saying that the existing Guix CLI is > pretty good, and we should be careful about changing it. I agree. Let's talk about it first :) Also, I agree about not touching "guix build". That one is mostly for package authors and it makes sense that it prints the stuff immediately.