[-- Attachment #1.1: Type: text/plain, Size: 2413 bytes --] Hi, Today I encountered an issue with Guix's user interface. I was trying to load a Scheme file defining a development environment with `guix environment --ad-hoc --load=file.scm`, but Guix kept telling me that the file did not exist even though I could swear it did: > $ head -n 1 development-environment.scm > (use-modules (gnu packages) > $ guix environment --ad-hoc --load=development-environment.scm > guix environment: error: failed to load 'development-environment.scm': No such file or directory After pulling my hair out for a while and then turning to `strace` I figured out that it was not actually that the file `development-environment.scm` did not exist, the issue was that the Scheme code in that file tried to load a file that did not exist. I set up a couple of different test cases to see if all errors were reported equally and to understand the issue better. Running a file that contains a syntax error indicates that there is an error in the file itself > $ guix environment --ad-hoc --load=syntax-error.scm > syntax-error.scm:2:1: missing closing parenthesis The same goes for when the code in the file being run throws an exception: > $ guix environment --ad-hoc --load=throw-exception.scm > guix environment: error: failed to load 'throw-exception.scm': > throw-exception.scm:1:0: banana But when the code in turn tries to load another file which does not exist it is reported as if the file itself is missing: > $ guix environment --ad-hoc --load=load-non-existing-file.scm > guix environment: error: failed to load 'load-non-existing-file.scm': No such file or directory I was able to find the source of the error message in `guix/ui.scm:378` and patched it to output the following message that makes more sense in this failure case: > $ ./pre-inst-env guix environment --ad-hoc --load=load-non-existing-file.scm > guix environment: error: failed to evaluate 'load-non-existing-file.scm', it raised the error: No such file or directory So here comes my questions: 1. Why is the file and line number not reported when the user provided scheme file fails to load another file? 2. Is it possible to modify guix so that it is? 3. If not, is the code path that I patched also used for other failures making the modification I demonstrated above a bad idea? 4. If so, is there a better way? I have attached the three small Scheme source code files used in the above examples. [-- Attachment #1.2: Type: text/html, Size: 2753 bytes --] [-- Attachment #2: load-non-existing-file.scm --] [-- Type: text/x-scheme, Size: 80 bytes --] (use-modules (ice-9 rdelim)) (with-input-from-file "non-existant" read-string) [-- Attachment #3: throw-exception.scm --] [-- Type: text/x-scheme, Size: 17 bytes --] (error "banana") [-- Attachment #4: syntax-error.scm --] [-- Type: text/x-scheme, Size: 2 bytes --] (
Hi, On Sun, 21 Feb 2021 at 10:46, Rovanion Luckey <rovanion.luckey@gmail.com> wrote: > 1. Why is the file and line number not reported when the user provided scheme file fails to load another file? Because Guile does not provide this information. --8<---------------cut here---------------start------------->8--- $ guile -s /tmp/load-non-existing-file.scm Backtrace: In ice-9/boot-9.scm: 1736:10 7 (with-exception-handler _ _ #:unwind? _ # _) In unknown file: 6 (apply-smob/0 #<thunk 7f42cf279540>) In ice-9/boot-9.scm: 718:2 5 (call-with-prompt ("prompt") #<procedure 7f42cf28b980 …> …) In ice-9/eval.scm: 619:8 4 (_ #(#(#<directory (guile-user) 7f42ceeb3f00>))) In ice-9/boot-9.scm: 2806:4 3 (save-module-excursion #<procedure 7f42ceea6180 at ice-…>) 4351:12 2 (_) In ice-9/ports.scm: 440:11 1 (call-with-input-file "non-existant" #<procedure 7f42c…> …) In unknown file: 0 (open-file "non-existant" "r" #:encoding #f # #f) ERROR: In procedure open-file: In procedure open-file: No such file or directory: "non-existant" --8<---------------cut here---------------end--------------->8--- > 2. Is it possible to modify guix so that it is? From my understanding, no. Well, it is not easy, but I could be wrong. > 3. If not, is the code path that I patched also used for other failures making the modification I demonstrated above a bad idea? Instead of modifying the "generic" message, it seems more appropriate to collect the error, i.e., add another case for the match. All the best, simon
[-- Attachment #1: Type: text/plain, Size: 218 bytes --] Thank you for your kind help. Thanks to you Zimon and Adrianos who answered off-list. I was able to whip up a patch that should help future users avoid my confusion: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46805 [-- Attachment #2: Type: text/html, Size: 438 bytes --]