* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 18:44 ` User-Friendlyness of Guix and non-scaryness, printing messages Danny Milosavljevic
@ 2017-05-28 19:01 ` Danny Milosavljevic
2017-05-28 20:35 ` Danny Milosavljevic
2017-05-28 19:20 ` Leo Famulari
2017-05-28 19:30 ` ng0
2 siblings, 1 reply; 23+ messages in thread
From: Danny Milosavljevic @ 2017-05-28 19:01 UTC (permalink / raw)
To: guix-devel
Aha, much better:
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index f050fad97..e4a3a98a1 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -196,6 +196,7 @@ specified in MANIFEST, a manifest object."
(when (equal? profile %current-profile)
(ensure-default-profile))
+ (parameterize ((current-build-output-port (%make-void-port "w")))
(let* ((prof-drv (run-with-store store
(profile-derivation manifest
#:hooks (if bootstrap?
@@ -230,7 +231,7 @@ specified in MANIFEST, a manifest object."
count)
count)
(display-search-paths entries (list profile)
- #:kind 'prefix))))))))
+ #:kind 'prefix)))))))))
^L
;;;
As I understand it, for failed builds, it will still retain the log file and all the log messages even after this, right?
Now to adapt guix system, too - looks more difficult.
Would it be possible to make a custom port that just waits for a line to be printed, then prints some custom text to stderr only, and so on? For the spinner, like:
In pseudo-code:
class port:
while True:
line = port.readline()
sys.stderr.write("\\")
line = port.readline()
sys.stderr.write("|")
line = port.readline()
sys.stderr.write("/")
line = port.readline()
sys.stderr.write("-")
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 19:01 ` Danny Milosavljevic
@ 2017-05-28 20:35 ` Danny Milosavljevic
2017-05-28 20:58 ` Danny Milosavljevic
0 siblings, 1 reply; 23+ messages in thread
From: Danny Milosavljevic @ 2017-05-28 20:35 UTC (permalink / raw)
To: guix-devel
And the spinner implementation:
(define p
(let ((index 0)
(spinner-chars "|\\-/"))
(define (spin)
(set! index (+ index 1))
(if (>= index (string-length spinner-chars))
(set! index 0))
(display (array-ref spinner-chars index))
(display "\b"))
(make-soft-port
(vector
(lambda (c) (if (char=? c #\newline) (spin) (write c))) ; putc
(lambda (s) (if (string-contains s "\n") (spin))) ; puts
(lambda () #t) ; flush
(lambda () #f) ; getc
(lambda () #t)) ; close
"w")))
(define (f)
(display "\n" p)
(f))
(f)
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 20:35 ` Danny Milosavljevic
@ 2017-05-28 20:58 ` Danny Milosavljevic
2017-05-30 15:11 ` Ludovic Courtès
0 siblings, 1 reply; 23+ messages in thread
From: Danny Milosavljevic @ 2017-05-28 20:58 UTC (permalink / raw)
To: guix-devel
And also the spinner integrated:
diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
index f050fad97..d9ac61122 100644
--- a/guix/scripts/package.scm
+++ b/guix/scripts/package.scm
@@ -46,6 +46,7 @@
#:use-module (srfi srfi-34)
#:use-module (srfi srfi-35)
#:use-module (srfi srfi-37)
+ #:use-module (rnrs io ports)
#:use-module (gnu packages)
#:autoload (gnu packages base) (canonical-package)
#:autoload (gnu packages guile) (guile-2.0)
@@ -187,6 +188,27 @@ denote ranges as interpreted by 'matching-generations'."
(else
(leave (G_ "invalid syntax: ~a~%") pattern)))))
+(define previous-output-port (current-error-port))
+
+(define spinner-port
+ (let ((index 0)
+ (spinner-chars "|\\-/"))
+ (define (spin)
+ (set! index (+ index 1))
+ (if (>= index (string-length spinner-chars))
+ (set! index 0))
+ (display (array-ref spinner-chars index) previous-output-port)
+ (display #\backspace previous-output-port)
+ (flush-output-port previous-output-port))
+ (make-soft-port
+ (vector
+ (lambda (c) (if (char=? c #\newline) (spin))) ; putc
+ (lambda (s) (if (string-contains s "\n") (spin))) ; puts
+ (lambda () #t) ; flush
+ (lambda () #f) ; getc
+ (lambda () #t)) ; close
+ "w")))
+
(define* (build-and-use-profile store profile manifest
#:key
bootstrap? use-substitutes?
@@ -196,6 +218,7 @@ specified in MANIFEST, a manifest object."
(when (equal? profile %current-profile)
(ensure-default-profile))
+ (parameterize ((current-build-output-port spinner-port))
(let* ((prof-drv (run-with-store store
(profile-derivation manifest
#:hooks (if bootstrap?
@@ -230,7 +253,7 @@ specified in MANIFEST, a manifest object."
count)
count)
(display-search-paths entries (list profile)
- #:kind 'prefix))))))))
+ #:kind 'prefix)))))))))
^L
;;;
^ permalink raw reply related [flat|nested] 23+ messages in thread* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 20:58 ` Danny Milosavljevic
@ 2017-05-30 15:11 ` Ludovic Courtès
0 siblings, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2017-05-30 15:11 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
Hi Danny,
Danny Milosavljevic <dannym@scratchpost.org> skribis:
> And also the spinner integrated:
>
> diff --git a/guix/scripts/package.scm b/guix/scripts/package.scm
> index f050fad97..d9ac61122 100644
> --- a/guix/scripts/package.scm
> +++ b/guix/scripts/package.scm
> @@ -46,6 +46,7 @@
> #:use-module (srfi srfi-34)
> #:use-module (srfi srfi-35)
> #:use-module (srfi srfi-37)
> + #:use-module (rnrs io ports)
> #:use-module (gnu packages)
> #:autoload (gnu packages base) (canonical-package)
> #:autoload (gnu packages guile) (guile-2.0)
> @@ -187,6 +188,27 @@ denote ranges as interpreted by 'matching-generations'."
> (else
> (leave (G_ "invalid syntax: ~a~%") pattern)))))
>
> +(define previous-output-port (current-error-port))
> +
> +(define spinner-port
> + (let ((index 0)
> + (spinner-chars "|\\-/"))
> + (define (spin)
> + (set! index (+ index 1))
> + (if (>= index (string-length spinner-chars))
> + (set! index 0))
> + (display (array-ref spinner-chars index) previous-output-port)
> + (display #\backspace previous-output-port)
> + (flush-output-port previous-output-port))
> + (make-soft-port
> + (vector
> + (lambda (c) (if (char=? c #\newline) (spin))) ; putc
> + (lambda (s) (if (string-contains s "\n") (spin))) ; puts
> + (lambda () #t) ; flush
> + (lambda () #f) ; getc
> + (lambda () #t)) ; close
> + "w")))
Nice hack! I don’t think we should incorporate it just right now; I
would prefer something that writes “building foo” or “downloading bar”
in addition to the spinner, like ‘wip-ui’ tries to do.
WDYT?
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 18:44 ` User-Friendlyness of Guix and non-scaryness, printing messages Danny Milosavljevic
2017-05-28 19:01 ` Danny Milosavljevic
@ 2017-05-28 19:20 ` Leo Famulari
2017-05-28 19:40 ` Danny Milosavljevic
` (2 more replies)
2017-05-28 19:30 ` ng0
2 siblings, 3 replies; 23+ messages in thread
From: Leo Famulari @ 2017-05-28 19:20 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 3542 bytes --]
On Sun, May 28, 2017 at 08:44:44PM +0200, Danny Milosavljevic wrote:
> Ideally, a successful build & installation of a package should look
> like this:
>
> $ guix package -i foobar
> $
Silence is golden!
> Nothing else. If you can't help it, then:
>
> $ guix package -i foobar
> Package foobar in version 2.3.2 has been successfully installed into your profile.
> $
[...]
> For a successful installation it should *never* print (as it does now):
>
> $ guix package -i foobar
> ...aphics/opentype -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/graphics/transforms -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mediastream -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mediastream/libwebrtc -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mock -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mock/mediasource -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/network -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/sql -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/text -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/text/icu -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/plugins -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/
This sample omits the most useful output, which is the summary of what
will be done. In my opinion, a successful run of `guix package` should
either print this summary and the name of the new generation, or be as
verbose as it is now.
> I think that a line containing something like
> "36pqsgbqi7kkkkn89sqrp2hyk3gxm8zv" (like install-file would print,
> too) should never appear in front of the user in normal operation.
>
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.
> Some programmer (!) colleagues of mine actually remarked something
> like "what is THAT? Looks scary" when they looked at what guix prints
> when I install something in Guix.
I understand that your colleagues share your opinion, but they are few,
and don't even use Guix, so we should not take this small sample too
seriously. We can all look at the interfaces of software or machines
that we don't use and feel confused, but this feeling doesn't mean very
much, in my opinion. I remember being mystified by car dashboards as
child. Since I learned to drive, I never think twice about them, and I
drive different cars and trucks often.
Command-line interfaces are not suitable for usage by "non-technical
users" anyways; they demand a GUI. Most of us are comfortable on the
command-line, but we should not forget that we are in an extremely small
minority. It would be great if everyone could learn to use their
computers with the command-line, which offers great power and
flexibility, but it's not a realistic goal, especially as new computer
users eschew "real" computers in favor of mobile phones.
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.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 19:20 ` Leo Famulari
@ 2017-05-28 19:40 ` Danny Milosavljevic
2017-05-28 19:47 ` Leo Famulari
` (2 more replies)
2017-05-30 1:47 ` "guix system" summary output? Danny Milosavljevic
2017-05-30 8:17 ` User-Friendlyness of Guix and non-scaryness, printing messages Roel Janssen
2 siblings, 3 replies; 23+ messages in thread
From: Danny Milosavljevic @ 2017-05-28 19:40 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
Hi Leo,
On Sun, 28 May 2017 15:20:58 -0400
Leo Famulari <leo@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.
^ permalink raw reply [flat|nested] 23+ messages in thread* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 19:40 ` Danny Milosavljevic
@ 2017-05-28 19:47 ` Leo Famulari
2017-05-28 21:12 ` Ludovic Courtès
2017-05-30 8:24 ` Ricardo Wurmus
2 siblings, 0 replies; 23+ messages in thread
From: Leo Famulari @ 2017-05-28 19:47 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]
On Sun, May 28, 2017 at 09:40:29PM +0200, Danny Milosavljevic wrote:
> On Sun, 28 May 2017 15:20:58 -0400
> Leo Famulari <leo@famulari.name> wrote:
> The scripts I mean are:
> > 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.
Right, but my point was that new tools are unfamiliar and intimidating
even to technical users. I might know how to use GCC, but I will still
find the interface and output of another language's compiler strange and
basically useless until I learn how to use 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.
Okay :) By the way, I know that my tastes are old-school and that I am
very conservative about changing things. We should think about this sort
of change before Guix 1.0.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 19:40 ` Danny Milosavljevic
2017-05-28 19:47 ` Leo Famulari
@ 2017-05-28 21:12 ` Ludovic Courtès
2017-05-31 22:26 ` Danny Milosavljevic
2017-05-30 8:24 ` Ricardo Wurmus
2 siblings, 1 reply; 23+ messages in thread
From: Ludovic Courtès @ 2017-05-28 21:12 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
Hello,
Danny Milosavljevic <dannym@scratchpost.org> 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’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 21:12 ` Ludovic Courtès
@ 2017-05-31 22:26 ` Danny Milosavljevic
2017-06-01 21:41 ` Ludovic Courtès
0 siblings, 1 reply; 23+ messages in thread
From: Danny Milosavljevic @ 2017-05-31 22:26 UTC (permalink / raw)
To: Ludovic Courtès; +Cc: guix-devel
Hi Ludo,
On Sun, 28 May 2017 23:12:44 +0200
ludo@gnu.org (Ludovic Courtès) wrote:
> Hello,
>
> Danny Milosavljevic <dannym@scratchpost.org> 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.
I forgot guix environment.
> 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
I'll check it out...
> 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>.
Hmm, is that the correct URL ? :)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-31 22:26 ` Danny Milosavljevic
@ 2017-06-01 21:41 ` Ludovic Courtès
0 siblings, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2017-06-01 21:41 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
Danny Milosavljevic <dannym@scratchpost.org> skribis:
> On Sun, 28 May 2017 23:12:44 +0200
> ludo@gnu.org (Ludovic Courtès) wrote:
>
>> Hello,
>>
>> Danny Milosavljevic <dannym@scratchpost.org> 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.
>
> I forgot guix environment.
>
>> 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
>
> I'll check it out...
>
>> 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>.
>
> Hmm, is that the correct URL ? :)
It was correct once upon a time. :-) Here’s the current one:
<https://nim-lang.org/blog/2017/01/08/version-0160-released.html>.
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 19:40 ` Danny Milosavljevic
2017-05-28 19:47 ` Leo Famulari
2017-05-28 21:12 ` Ludovic Courtès
@ 2017-05-30 8:24 ` Ricardo Wurmus
2017-06-16 11:42 ` Danny Milosavljevic
2 siblings, 1 reply; 23+ messages in thread
From: Ricardo Wurmus @ 2017-05-30 8:24 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
> 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. [They’re] not gonna frame the output and hang it on a wall :)
I agree that Guix is too verbose by default. It would be sufficient if
Guix told the user that it is building from source for some reason.
Upon failure it can print the location of the build log.
--
Ricardo
GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC
https://elephly.net
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-30 8:24 ` Ricardo Wurmus
@ 2017-06-16 11:42 ` Danny Milosavljevic
2017-06-17 20:16 ` Ludovic Courtès
0 siblings, 1 reply; 23+ messages in thread
From: Danny Milosavljevic @ 2017-06-16 11:42 UTC (permalink / raw)
To: Ricardo Wurmus; +Cc: guix-devel
Hi,
On Tue, 30 May 2017 10:24:34 +0200
Ricardo Wurmus <rekado@elephly.net> wrote:
> Upon failure it can print the location of the build log.
I'm trying to get this to work but
guix build --log-file foo
doesn't seem to print the location of the build log in the failure case...
Is it possible to get to it somehow?
Apparently the log files go into log/guix/drvs - but I can't find the place where the build log is created in the first place...
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-06-16 11:42 ` Danny Milosavljevic
@ 2017-06-17 20:16 ` Ludovic Courtès
0 siblings, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2017-06-17 20:16 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
Hello,
Danny Milosavljevic <dannym@scratchpost.org> skribis:
> On Tue, 30 May 2017 10:24:34 +0200
> Ricardo Wurmus <rekado@elephly.net> wrote:
>
>> Upon failure it can print the location of the build log.
>
> I'm trying to get this to work but
>
> guix build --log-file foo
>
> doesn't seem to print the location of the build log in the failure case...
It should work (for local builds at least). Perhaps you also need
--no-grafts? Or maybe there’s a bug.
> Is it possible to get to it somehow?
Sure, just look for in in /var/log/guix/drvs.
> Apparently the log files go into log/guix/drvs - but I can't find the place where the build log is created in the first place...
The logs are named after the derivation; see ‘log-file’ in (guix store).
HTH!
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* "guix system" summary output?
2017-05-28 19:20 ` Leo Famulari
2017-05-28 19:40 ` Danny Milosavljevic
@ 2017-05-30 1:47 ` Danny Milosavljevic
2017-05-30 11:05 ` Danny Milosavljevic
2017-05-30 15:47 ` Ludovic Courtès
2017-05-30 8:17 ` User-Friendlyness of Guix and non-scaryness, printing messages Roel Janssen
2 siblings, 2 replies; 23+ messages in thread
From: Danny Milosavljevic @ 2017-05-30 1:47 UTC (permalink / raw)
To: Leo Famulari, guix-devel
> This sample omits the most useful output, which is the summary of what
> will be done.
Just tested with the spinner so I could actually (potentially) see the summary.
It seems that "guix package" prints such a summary (yay!), but "guix system reconfigure" doesn't. The latter just starts downloading stuff and then builds stuff - no summary anywhere:
;;; note: source file /x/home/dannym/src/guix/guix/ui.scm
;;; newer than compiled /x/home/dannym/src/guix/guix/ui.go
guix system: warning: Your Guix installation is 476 days old.
guix system: warning: Consider running 'guix pull' followed by
'guix system reconfigure' to get up-to-date packages and security updates.
substitute: updating list of substitutes from 'https://bayfront.guixsd.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://bayfront.guixsd.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
substitute: updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
updating list of substitutes from 'https://bayfront.guixsd.org'... 100.0%
updating list of substitutes from 'https://mirror.hydra.gnu.org'... 100.0%
Downloading https://mirror.hydra.gnu.org/guix/nar/zv7rfn8wj4g0nrjzfqgpdnibwy8rjq9q-adwaita-icon-theme-3.24.0.tar.xz (19.8MiB installed)...
adwaita-icon-theme-3.24.0.tar.xz 19.8MiB 1.2MiB/s 00:16 [####################] 100.0%
updating list of substitutes from 'https://bayfront.guixsd.org'... 100.0%
Downloading https://mirror.hydra.gnu.org/guix/nar/b06kc32xcs4kmidi82p4agrmnypri935-cups-2.2.1-source.tar.gz (9.0MiB installed)...
cups-2.2.1-source.tar.gz 9.0MiB 1.6MiB/s 00:06 [####################] 100.0%
|
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: "guix system" summary output?
2017-05-30 1:47 ` "guix system" summary output? Danny Milosavljevic
@ 2017-05-30 11:05 ` Danny Milosavljevic
2017-05-30 15:47 ` Ludovic Courtès
1 sibling, 0 replies; 23+ messages in thread
From: Danny Milosavljevic @ 2017-05-30 11:05 UTC (permalink / raw)
To: Leo Famulari, guix-devel
On Tue, 30 May 2017 03:47:46 +0200
Danny Milosavljevic <dannym@scratchpost.org> wrote:
> > This sample omits the most useful output, which is the summary of what
> > will be done.
>
> Just tested with the spinner so I could actually (potentially) see the summary.
>
> It seems that "guix package" prints such a summary (yay!), but "guix system reconfigure" doesn't. The latter just starts downloading stuff and then builds stuff - no summary anywhere:
And now it does print the summary. I've got no idea what's different now.
guix system: warning: Your Guix installation is 477 days old.
guix system: warning: Consider running 'guix pull' followed by
'guix system reconfigure' to get up-to-date packages and security updates.
The following derivations will be built:
/gnu/store/0sm3cp68x056gq23a93l37bb725vhfi4-system.drv
/gnu/store/jmnp4mfa5iv8ra01gzndb4xlf7kkw2ji-grub.cfg.drv
/gnu/store/lmwi7z6s8601swnyyygv9ycdq6bjcmy8-m4-1.4.18.tar.xz.drv
...
\
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: "guix system" summary output?
2017-05-30 1:47 ` "guix system" summary output? Danny Milosavljevic
2017-05-30 11:05 ` Danny Milosavljevic
@ 2017-05-30 15:47 ` Ludovic Courtès
1 sibling, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2017-05-30 15:47 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
Danny Milosavljevic <dannym@scratchpost.org> skribis:
>> This sample omits the most useful output, which is the summary of what
>> will be done.
>
> Just tested with the spinner so I could actually (potentially) see the summary.
>
> It seems that "guix package" prints such a summary (yay!), but "guix system reconfigure" doesn't. The latter just starts downloading stuff and then builds stuff - no summary anywhere:
Probably this relates to grafts: store items need to be
substitutable/available so we can determine whether they need to be
grafted.
What happens with ‘guix system … --no-grafts’?
Thanks,
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 19:20 ` Leo Famulari
2017-05-28 19:40 ` Danny Milosavljevic
2017-05-30 1:47 ` "guix system" summary output? Danny Milosavljevic
@ 2017-05-30 8:17 ` Roel Janssen
2017-05-30 13:56 ` Arun Isaac
2 siblings, 1 reply; 23+ messages in thread
From: Roel Janssen @ 2017-05-30 8:17 UTC (permalink / raw)
To: Leo Famulari; +Cc: guix-devel
Leo Famulari writes:
> On Sun, May 28, 2017 at 08:44:44PM +0200, Danny Milosavljevic wrote:
>> Ideally, a successful build & installation of a package should look
>> like this:
>>
>> $ guix package -i foobar
>> $
>
> Silence is golden!
>
>> Nothing else. If you can't help it, then:
>>
>> $ guix package -i foobar
>> Package foobar in version 2.3.2 has been successfully installed into your profile.
>> $
>
> [...]
>
>> For a successful installation it should *never* print (as it does now):
>>
>> $ guix package -i foobar
>> ...aphics/opentype -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/graphics/transforms -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mediastream -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mediastream/libwebrtc -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mock -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/mock/mediasource -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/network -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/sql -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/text -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/platform/text/icu -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/Source/WebCore/plugins -I/tmp/guix-build-webkitgtk-2.16.3.drv-0/webkitgtk-2.16.3/
>
> This sample omits the most useful output, which is the summary of what
> will be done. In my opinion, a successful run of `guix package` should
> either print this summary and the name of the new generation, or be as
> verbose as it is now.
>
>> I think that a line containing something like
>> "36pqsgbqi7kkkkn89sqrp2hyk3gxm8zv" (like install-file would print,
>> too) should never appear in front of the user in normal operation.
>>
> 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' should be as verbose as it is now. It is
actually very useful for detecting little things like missing
dependencies or wrong configuration options when building a package.
But I think 'guix package' can be made a lot more user-friendly by not
showing the build output (by default). The summary of what will be
installed, and some progress indicator or at least something moving to
show the user it's doing something, and eventually the success or
failure message is enough.
You know what would be cool? A progress indicator like so:
Building derivation 6 of 110..
With '6' progressing up to '110' as soon as a build succeeds.
It would be much more useful to me than to see these g++ commands (when
installing programs).
>> Some programmer (!) colleagues of mine actually remarked something
>> like "what is THAT? Looks scary" when they looked at what guix prints
>> when I install something in Guix.
>
> I understand that your colleagues share your opinion, but they are few,
> and don't even use Guix, so we should not take this small sample too
> seriously. We can all look at the interfaces of software or machines
> that we don't use and feel confused, but this feeling doesn't mean very
> much, in my opinion. I remember being mystified by car dashboards as
> child. Since I learned to drive, I never think twice about them, and I
> drive different cars and trucks often.
>
> Command-line interfaces are not suitable for usage by "non-technical
> users" anyways; they demand a GUI. Most of us are comfortable on the
> command-line, but we should not forget that we are in an extremely small
> minority. It would be great if everyone could learn to use their
> computers with the command-line, which offers great power and
> flexibility, but it's not a realistic goal, especially as new computer
> users eschew "real" computers in favor of mobile phones.
But at least we can try to make them more non-technical-user-friendly
wherever it doesn't hurt us. And I think 'guix package' is such a
case.
We are also hiding a lot of information on 'guix package
--list-generations', because we only display the difference between two
generations. I think it looks much better in practice than it did
before.
> 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 don't think we are making the CLI less powerful by not showing the
build output in the 'guix package' command. When the build fails, you
can review the build log. And a failure is something you don't expect
when you are installing packages. That's something we use 'guix build'
for.
Kind regards,
Roel Janssen
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-30 8:17 ` User-Friendlyness of Guix and non-scaryness, printing messages Roel Janssen
@ 2017-05-30 13:56 ` Arun Isaac
2017-05-30 14:32 ` Christopher Allan Webber
2017-05-30 15:13 ` Ludovic Courtès
0 siblings, 2 replies; 23+ messages in thread
From: Arun Isaac @ 2017-05-30 13:56 UTC (permalink / raw)
To: guix-devel
> But I think 'guix package' can be made a lot more user-friendly by not
> showing the build output (by default). The summary of what will be
> installed, and some progress indicator or at least something moving to
> show the user it's doing something, and eventually the success or
> failure message is enough.
Is it possible to have `guix package' NOT build from source? I really
hate it when big packages like icecat, epiphany, or libreoffice start
building on my machine. It takes about a day for each one of these
packages to build on my machine, and they generally swap so much into
HDD, that I can hardly do anything else when building. Because of this
inconvenience, I keep postponing upgrading my packages.
Also, sometimes having to "--fallback" to building source is such a
pain. I think the end user needs a Debian-like experience (or like other
conventional non-source distros) where they can ALWAYS download the
latest packages from the repos.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-30 13:56 ` Arun Isaac
@ 2017-05-30 14:32 ` Christopher Allan Webber
2017-05-30 15:58 ` Arun Isaac
2017-05-30 15:13 ` Ludovic Courtès
1 sibling, 1 reply; 23+ messages in thread
From: Christopher Allan Webber @ 2017-05-30 14:32 UTC (permalink / raw)
To: Arun Isaac; +Cc: guix-devel
Arun Isaac writes:
>> But I think 'guix package' can be made a lot more user-friendly by not
>> showing the build output (by default). The summary of what will be
>> installed, and some progress indicator or at least something moving to
>> show the user it's doing something, and eventually the success or
>> failure message is enough.
>
> Is it possible to have `guix package' NOT build from source? I really
> hate it when big packages like icecat, epiphany, or libreoffice start
> building on my machine. It takes about a day for each one of these
> packages to build on my machine, and they generally swap so much into
> HDD, that I can hardly do anything else when building. Because of this
> inconvenience, I keep postponing upgrading my packages.
>
> Also, sometimes having to "--fallback" to building source is such a
> pain. I think the end user needs a Debian-like experience (or like other
> conventional non-source distros) where they can ALWAYS download the
> latest packages from the repos.
There's a bug I opened about adding an --only-substitutes option:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=26608
Ludo seems to support it, so I guess really someone just needs to
implement it. It would result in a lot less churn for a lot of us :)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-30 13:56 ` Arun Isaac
2017-05-30 14:32 ` Christopher Allan Webber
@ 2017-05-30 15:13 ` Ludovic Courtès
1 sibling, 0 replies; 23+ messages in thread
From: Ludovic Courtès @ 2017-05-30 15:13 UTC (permalink / raw)
To: Arun Isaac; +Cc: guix-devel
Arun Isaac <arunisaac@systemreboot.net> skribis:
> Is it possible to have `guix package' NOT build from source?
We should definitely add an option for this. See also
<https://bugs.gnu.org/26608>.
Ludo’.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: User-Friendlyness of Guix and non-scaryness, printing messages
2017-05-28 18:44 ` User-Friendlyness of Guix and non-scaryness, printing messages Danny Milosavljevic
2017-05-28 19:01 ` Danny Milosavljevic
2017-05-28 19:20 ` Leo Famulari
@ 2017-05-28 19:30 ` ng0
2 siblings, 0 replies; 23+ messages in thread
From: ng0 @ 2017-05-28 19:30 UTC (permalink / raw)
To: Danny Milosavljevic; +Cc: guix-devel
Hi,
Danny Milosavljevic transcribed 15K bytes:
> Hi,
>
> so bug#26941 (which is only tangentially related) has made me think about a long-standing usability wart of Guix:
>
> The verbosity of Guix messages is really off-putting for regular users.
>
> Ideally, a successful build & installation of a package should look like this:
>
> $ guix package -i foobar
> $
>
> Nothing else. If you can't help it, then:
>
> $ guix package -i foobar
> Package foobar in version 2.3.2 has been successfully installed into your profile.
> $
>
> For a successful installation it should *never* print (as it does now):
>
> $ guix package -i foobar
> [... 20 pages of cryptic text]
> Package foobar has been successfully installed into your profile.
> $
>
> I think that a line containing something like "36pqsgbqi7kkkkn89sqrp2hyk3gxm8zv" (like install-file would print, too) should never appear in front of the user in normal operation.
>
> Some programmer (!) colleagues of mine actually remarked something like "what is THAT? Looks scary" when they looked at what guix prints when I install something in Guix.
>
> Really, printing that much noise is an usability bug.
>
> Arun mentioned that he wants to see that something is still happening and therefore wants something printed. I agree - but it should only print and update one line total.
>
> For example, if we wanted a progress monitor, that could look like this (this should include all the dependencies in the same progress display):
>
> $ guix package -i foobar
> Installing... [20%] \
> ^ Spinner that spins, say, every time a line is added to the log file.
>
> And later when progress is 100%, changing to
>
> $ guix package -i foobar
> Installation successful
> $
>
> I think that the detailed messages are good to have in the event that an installation fails. But even then it should just print a message like this (and here, it really should print it):
>
> $ guix package -i foobar
> Installation failed. For more details, you can invoke "guix build --log-file `guix build -d foobar`" (without double quotes). In order to report a bug, please send a message to <bug-guix@gnu.org>.
> $
>
> Or it could invoke "guix build --log-file `guix build -d foobar`" on its own and just print the resulting name.
>
> It should NOT print the detailed messages automatically.
>
> So all in all I'd really like much less verbosity on the console. I actually use guix behind a wrapper script of mine that supresses all non-error messages for common cases (it redirects stdout to /dev/null) - and it's *still* pretty bad. I think that's because all the build output is printed to stderr by build.scm , regardless of whether the container printed it to stdout or stderr. Is that correct?
>
> Could we please make "guix package -i" use "guix build -q" to make stdout and stderr go into the log files only?
>
> Furthermore, I think even the guix download lines are too noisy in the successful case. Guix should really just update one line for the entire thing, downloading, building, profile updating, everything.
>
> The usual UNIX design, too, is that if everything works, UNIX prints nothing. As soon as something is printed my first feeling is that it's something bad (especially with 20 pages :P). And really, no one cares what the current gcc command is - as long as it works.
>
> If UNIX printed everything it did it would look very noisy and be very slow (printing takes time).
>
> I think "guix pull" is nice in this regard. It just shows a progress bar. Nothing else. Because a normal user doesn't care that now it compiles gnu/foo/bar.scm into e5y35334436743987463464363-foo/lib/afrewtew/tw/teww.
>
> WDYT?
>
>
I agree to some extent. From a daily usage perspective, it is not nice.
Especially looking at it from where I originally started, slackware and slackware based systems,
it is too much. Simplicity is better than noise.
As a developer I appreciate the verbosity, seeing exactly *why*
the build failed.
I don't want that for people who just want to work with Guix or
GuixSD.
But as a developer I want the default to be to print exactly
this noise, so I must be able to override it globally or for
the process I run.
^ permalink raw reply [flat|nested] 23+ messages in thread