Hi Guix, I've finally figured out, what causes this issue.
Guix repl uses the following code to call scripts: ``` (unless (null? script) ;; Run script (save-module-excursion (lambda () (set-program-arguments script) (set-user-module) (load-in-vicinity "." (car script))))) ``` But `guix describe` (which is used to initialize %package-module-path) has the following: ``` (define current-profile (mlambda () "Return the profile (created by 'guix pull') the calling process lives in, or #f if this is not applicable." (match (command-line) ((program . _) (and (string-suffix? "/bin/guix" program) [...]))))) (define current-profile-entries [...]) (define current-channel-entries [...]) (define package-path-entries [...]) ``` Each of these procedures depends on the previous, building up a chain that fails exactly in the case where we (set-program-arguments [...]) with a script other than the current channel's guix (which is probably the way you'd want to use `guix repl`). There are some ways of resolving this. One would be to access earlier versions of "command-line" – it does resolve to a fluid, but that fluid itself is not exposed to Guile. Perhaps there might be some FFI magic to access it. You could also set up your script to fake being a Guix command by setting the command line to be (cons* "$HOME/.config/guix/current/bin/guix" "repl" (command-line)), i.e. reconstructing the way your script has been invoked. This would obviously break if you were to call it with a different Guix, also you'd have to resolve $HOME instead of writing it like that, but you'd have access to your channels. On the other hand, we could patch `guix repl` to initialize %package- module-path earlier (still leaving `guix describe` broken) or somehow try to work around that issue in `guix describe`. Regards, Leo