Lack of error message in several guix subcommands

  • Done
  • quality assurance status badge
Details
3 participants
  • Alice BRENON
  • Ludovic Courtès
  • zimoun
Owner
unassigned
Submitted by
Alice BRENON
Severity
important
A
A
Alice BRENON wrote on 28 Oct 2021 19:15
(address . bug-guix@gnu.org)
20211028191517.719afb83@ens-lyon.fr
Hi list,

I was giving guix shell a try today and noticed this annoying lack of
relevant feedback from the tool: when running on a particularly
malformed guix.scm, either by auto-loading or by explicitely passing -f
guix.scm, guix shell returned in error ($? == 1) without printing any
error message, which is a bit unhelpful.

The particular malformed guix.scm simply contains an extra parenthesis
after the package definition. Compare to the case when the package
definition lacks the final parenthesis, which yields a helpful message
like this:

/tmp/bug/guix.scm:25:1: missing closing parenthesis

This is not specific to guix shell because I could then reproduce this
behaviour with other commands like guix environment or guix build.

Find attached the file I've been using to reproduce the bug, which is
essentially the "hello" package example from the manual[1] without the
(define-public …) layer, in order for the top-level expression
contained in the file to be directly a package usable by -f (-l for
guix environment) and not have to put hello on the last line. The
version attached is correct and will allow guix shell -f guix.scm to
enter an environment where hello is installed. Remove a parenthesis,
you should have the above message. Add one, on the contrary, and you
should get nothing but silence.

I'm using guix on Guix System, and pulled this morning:

guix 5cbf9a4
branche?: master
commit : 5cbf9a48d766191d8f17b2e9d1cf7b7db69b99ea


Regards,

Alice


[1]
(define-module (gnu packages hello) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix build-system gnu) #:use-module (guix licenses) #:use-module (gnu packages gawk)) (package (name "hello") (version "2.10") (source (origin (method url-fetch) (uri (string-append "mirror://gnu/hello/hello-" version ".tar.gz")) (sha256 (base32 "0ssi1wpaf7plaswqqjwigppsg5fyh99vdlb9kzl7c9lng89ndq1i")))) (build-system gnu-build-system) (arguments '(#:configure-flags '("--enable-silent-rules"))) (inputs `(("gawk" ,gawk))) (synopsis "Hello, GNU world: An example GNU package") (description "Guess what GNU Hello prints!") (home-page "https://www.gnu.org/software/hello/") (license gpl3+)))
L
L
Ludovic Courtès wrote on 29 Oct 2021 00:45
control message for bug #51463
(address . control@debbugs.gnu.org)
874k904vla.fsf@gnu.org
severity 51463 important
quit
L
L
Ludovic Courtès wrote on 7 Nov 2021 23:14
Re: bug#51463: Lack of error message in several guix subcommands
(name . Alice BRENON)(address . alice.brenon@ens-lyon.fr)(address . 51463-done@debbugs.gnu.org)
87ee7rk3zn.fsf@gnu.org
Hi Alice,

Alice BRENON <alice.brenon@ens-lyon.fr> skribis:

Toggle quote (6 lines)
> I was giving guix shell a try today and noticed this annoying lack of
> relevant feedback from the tool: when running on a particularly
> malformed guix.scm, either by auto-loading or by explicitely passing -f
> guix.scm, guix shell returned in error ($? == 1) without printing any
> error message, which is a bit unhelpful.

I believe commit 4d59596a1c5f6b20870e619cbf67068ac7dd64ff fixes it (the
issue affected ‘read-error’ exceptions for reasons other than missing
closing parentheses).

Let me know if anything’s amiss.

Thanks!

Ludo’.
Closed
Z
Z
zimoun wrote on 8 Nov 2021 11:45
(address . 51463-done@debbugs.gnu.org)
86bl2vsz7l.fsf@gmail.com
Hi Ludo,

On Sun, 07 Nov 2021 at 23:14, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (4 lines)
> I believe commit 4d59596a1c5f6b20870e619cbf67068ac7dd64ff fixes it (the
> issue affected ‘read-error’ exceptions for reasons other than missing
> closing parentheses).

With your fix, I am questioning the ’if’ test. Introduced before
524c9800afb433cc474132185d8e37f72004adb3.


For instance, it reads,

Toggle snippet (3 lines)
/tmp/pkgs/foo.scm:26:1: missing closing parenthesis

when Guile reports,

Toggle snippet (3 lines)
/tmp/foo.scm:25:1: unexpected end of input while searching for: )

and this message is parsed to catch and report the first message,
instead.

Well, I agree that on one hand, Guile error messages seem badly worded
for newcomers. On the other hand, post
4d59596a1c5f6b20870e619cbf67068ac7dd64ff, the message for extra
parenthesis,

Toggle snippet (3 lines)
guix repl: error: read error while loading '/tmp/pkgs/foo.scm': /tmp/pkgs/foo.scm:25:23: unexpected ")"

is inconsistent from the one for missing parenthesis. Other said, the
then-branch uses ’format’ and the else-branch uses ’report-error’.


Some Guile errors are sometimes cryptic (the reason of “missing closing
parenthesis” I guess), therefore, the question is: do we add ’cond’
branches for each cases? Using “report-error” for all? Or do we only
rely on Guile error messages? Dropping ’if’ test.


Last, checking and playing with all that, I note that this catch is done
when using ’load*’ and nothing is done for option ’load-path’.


Cheers,
simon
Closed
?
Your comment

This issue is archived.

To comment on this conversation send an email to 51463@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 51463
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch