Hi Leo, On Sun, 28 May 2017 15:20:58 -0400 Leo Famulari <l...@famulari.name> 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.
