> Hello. Is it possible to get better error reporting in the following > example? > > $ sudo guix system -K -L /home/vlad/Code/fullmeta-guix/channel container > os.scm > > [...] I also face this very problem when using the "-L" switch with other commands, e.g. `guix shell`. Is there some missed-by-us way to get error reports from modules? Wojtek -- (sig_start) website: https://koszko.org/koszko.html PGP: https://koszko.org/key.gpg fingerprint: E972 7060 E3C5 637C 8A4F 4B42 4BC5 221C 5A79 FD1A ♥ R29kIGlzIHRoZXJlIGFuZCBsb3ZlcyBtZQ== | ÷ c2luIHNlcGFyYXRlZCBtZSBmcm9tIEhpbQ== ✝ YnV0IEplc3VzIGRpZWQgdG8gc2F2ZSBtZQ== | ? U2hhbGwgSSBiZWNvbWUgSGlzIGZyaWVuZD8= -- (sig_end) On Mon, 27 Mar 2023 14:52:26 +0100 Vladilen Kozin wrote: > Hello. Is it possible to get better error reporting in the following > example? > > $ sudo guix system -K -L /home/vlad/Code/fullmeta-guix/channel container > os.scm > > And our os.scm imports some services defined in our channel above. Should > there be an error in one of them, however, the stack trace only talks about > inability to find that service symbol but otherwise fails to report any > errors that may've happened when loading modules from our -L location above. > > Case in point. In one of the modules, I habitually used Clojury syntax and > wrote: > > (define foo [1 2]) > > (define foo-service > (list > (shepherd-service ... #$foo ...))) > > (define foo-service-type ...) > > Running the above OS derivation reports: > ``` > Backtrace: > In guix/store.scm: > ... bt here ... > ice-9/boot-9.scm:1685:16: In procedure raise-exception: > error: foo-service-type: unbound variable > ``` > > Backtrace has all modules and files either unknown or gensymed - so not > much use. > It isn't wrong, but e.g. attempting to [1 2] in Guile repl would tell you > "Wrong type to apply: 1" and loading this file would give you the location > ... probably :) > > Feels like defining shepherd services involves some dark arts and buckets > of time when you can't tell what went wrong where. > > Thank you >