emacs-guix: guix-pull invalid input error

Recently (the last week or two?) I've run into this problem where if I attempt to use guix-pull, which runs a "guix pull" from the *Guix REPL*, I get this error:

```

scheme@(emacs-guix)> (guix-command "pull")

Updating channel 'guix' from Git repository at 'https://git.savannah.gnu.org/git/guix.git'...

Building from this channel:

guix https://git.savannah.gnu.org/git/guix.git 2a6d964

guix pull: error: gnu/packages/commencement.scm:3333:4: package `guile@3.0.9' has an invalid input: ("source" #<origin "mirror://gnu/guile/guile-3.0.9.tar.xz" #<content-hash sha256:03bm1mnfc9kkg2ls942a0js7bxrdzmcffgrgg6anwdmjfan2a9hs> () 7f8e03e0f840>)

$12 = #t

```

However, I have no trouble doing a normal guix pull from the command-line. I have the same error running this with "emacs -q".

I am running GNU Emacs 30.0.92 (build 2, x86_64-pc-linux-gnu, GTK+ Version 3.24.41, cairo version 1.18.0) of 2024-10-29.

Here is my system information:

```

christopher@theoden

-------------------

OS: Guix System x86_64

Host: OptiPlex 9020 00

Kernel: 5.15.167-gnu

Uptime: 30 days, 8 hours, 44 mins

Packages: 167 (guix-system), 248 (guix-user)

Shell: bash 5.1.16

Resolution: 1920x1080

DE: GNOME

Theme: Adwaita [GTK2/3]

Icons: Adwaita [GTK2/3]

Terminal: launch-local-em

CPU: Intel i5-4570 (4) @ 3.600GHz

GPU: AMD ATI Radeon HD 8490 / R5 235X OEM

GPU: Intel HD Graphics

Memory: 4596MiB / 15914MiB

```

``` guix describe

Generation 151 Oct 28 2024 08:31:51 (current)

guix 4009d1d

repository URL: https://git.savannah.gnu.org/git/guix.git

branch: master

commit: 4009d1de954d694cb11af391d4113d29c5c1379d

```

--

? Christopher Howard

? gemini://gem.librehacker.com

? http://gem.librehacker.com

?????? ??? ????? ?? ????? ??? ????

From what I can tell, the only place that &package-input-error can be

raised from is guix/packages.scm:41:25. From the error, it seems that

input

(\"source\" #<origin \"mirror://gnu/guile/guile-3.0.9.tar.xz\"

#<content-hash

sha256:03bm1mnfc9kkg2ls942a0js7bxrdzmcffgrgg6anwdmjfan2a9hs> ()

7efc797e9c00>)

is not matching any of the match candidates in the expand-input procedure

in (guix packages). Does anything about this input look malformed,

or...?

--

Christopher Howard

I discovered that if I go to Gnome console, set the GUILE_LOAD_PATH

appropriately for the emacs-guix scheme code, run «,re (emacs-guix),»

and then run (guix-command "pull") that the pull completes without any

issues.

This seems to imply that the problem is somehow root in geiser or how

geiser interacts with guile.

--

Christopher Howard

Christopher Howard <christopher@librehacker.com> writes:

Out of curiosity, does the below raise an assertion error for you when

GUILE_LOAD_PATH is _not_ set "appropriately"?

#+begin_src emacs-lisp

(let ((guile-load-path (split-string (getenv "GUILE_LOAD_PATH") ":")))

(dolist (suffix '("guix/current/share/guile/site/3.0"

;; https://www.mail-archive.com/help-guix@gnu.org/msg13819.html

"guix-module-union/share/guile/site/3.0"))

(cl-assert (cl-some (lambda (x)

(string-suffix-p suffix x))

guile-load-path))))

#+end_src

--

Suhail

Suhail Singh <suhailsingh247@gmail.com> writes:

Hi, this is a little confusing since my example involved working outside

of Emacs, running Scheme from the guix repl. Are you wanting this elisp

code run before/after emacs-guix.el is loaded in Emacs? Anyhow, if I

just execute (eval-last-sexp) the code you sent, I get this error:

```

Debugger entered--Lisp error: (cl-assertion-failed ((cl-some (lambda (x) (string-suffix-p suffix x)) guile-load-path) nil))

cl--assertion-failed((cl-some (lambda (x) (string-suffix-p suffix x)) guile-load-path))

(or (cl-some #'(lambda (x) (string-suffix-p suffix x)) guile-load-path) (cl--assertion-failed '(cl-some (lambda (x) (string-suffix-p suffix x)) guile-load-path)))

(progn (or (cl-some #'(lambda (x) (string-suffix-p suffix x)) guile-load-path) (cl--assertion-failed '(cl-some (lambda (x) (string-suffix-p suffix x)) guile-load-path))) nil)

(let ((suffix (car tail))) (progn (or (cl-some #'(lambda (x) (string-suffix-p suffix x)) guile-load-path) (cl--assertion-failed '(cl-some (lambda (x) (string-suffix-p suffix x)) guile-load-path))) nil) (setq tail (cdr tail)))

(while tail (let ((suffix (car tail))) (progn (or (cl-some #'(lambda (x) (string-suffix-p suffix x)) guile-load-path) (cl--assertion-failed '(cl-some (lambda ... ...) guile-load-path))) nil) (setq tail (cdr tail))))

(let ((tail '("guix/current/share/guile/site/3.0" "guix-module-union/share/guile/site/3.0"))) (while tail (let ((suffix (car tail))) (progn (or (cl-some #'(lambda ... ...) guile-load-path) (cl--assertion-failed '(cl-some ... guile-load-path))) nil) (setq tail (cdr tail)))))

(let ((guile-load-path (split-string (getenv "GUILE_LOAD_PATH") ":"))) (let ((tail '("guix/current/share/guile/site/3.0" "guix-module-union/share/guile/site/3.0"))) (while tail (let ((suffix (car tail))) (progn (or (cl-some #'... guile-load-path) (cl--assertion-failed '...)) nil) (setq tail (cdr tail))))))

eval((let ((guile-load-path (split-string (getenv "GUILE_LOAD_PATH") ":"))) (let ((tail '("guix/current/share/guile/site/3.0" "guix-module-union/share/guile/site/3.0"))) (while tail (let ((suffix (car tail))) (progn (or (cl-some ... guile-load-path) (cl--assertion-failed ...)) nil) (setq tail (cdr tail)))))) nil)

elisp--eval-last-sexp(nil)

#f(compiled-function () #<bytecode 0x2999fd94511e2>)()

handler-bind-1(#f(compiled-function () #<bytecode 0x2999fd94511e2>) (error) eval-expression--debug)

eval-last-sexp(nil)

funcall-interactively(eval-last-sexp nil)

call-interactively(eval-last-sexp nil nil)

command-execute(eval-last-sexp)

```

--

Christopher Howard

Christopher Howard <christopher@librehacker.com> writes:

I am confused (as well). I thought you were running the command via the

"*Guix REPL*" buffer created by emacs-guix. Perhaps not? I'll share

below some thoughts as well as reasons for my curiosity. Please use

your judgment in determining whether or not they are applicable to your

situation.

It's possible that I'm mistaken, but my understanding of emacs-guix was

that it invoked a Guile REPL (even though it refers to it as a Guix

REPL). This can be confirmed by evaluating "(command-line)" in the

"*Guix REPL*" buffer (which on my machine, on a foreign distro, shows

guile).

As long as emacs-guix is not modifying the GUILE_LOAD_PATH environment

variable, it didn't matter when the code was evaluated.

The error you encountered could be due to a difference in %load-path

between the emacs-guix "*Guix REPL*" buffer vs %load-path when one runs

"guix repl" directly on the shell. The "guix-module-union" entry may be

of interest.

On my machine, I have to take some extra steps to ensure that said entry

exists in GUILE_LOAD_PATH (i.e., the %load-path when one loads the guile

repl).

--

Suhail

So, when inside Emacs, it appears that emacs-guix, after launching the *Guix REPL* and *Guix Internal REPL*, adds it's own scheme code to the paths in %load-path. In either of these REPLs, I can see that the emacs-guix scheme code is the first entry in the list:

```

scheme@(emacs-guix)> %load-path

$13 = ("/home/christopher/Repos/emacs-guix/scheme" "/home/christopher/.config/guix/current/share/guile/site/3.0" "/gnu/store/60hgms029zpd92w065g7lgnq5vw5rd7b-emacs-geiser-guile-0.28.3/share/emacs/site-lisp/geiser-guile-0.28.3/src" "/home/christopher/.guix-home/profile/share/guile/site/3.0" "/home/christopher/.guix-profile/share/guile/site/3.0" "/run/current-system/profile/share/guile/site/3.0" "/gnu/store/mfkz7fvlfpv3ppwbkv0imb19nrf95akf-guile-3.0.9/share/guile/3.0" "/gnu/store/mfkz7fvlfpv3ppwbkv0imb19nrf95akf-guile-3.0.9/share/guile/site/3.0" "/gnu/store/mfkz7fvlfpv3ppwbkv0imb19nrf95akf-guile-3.0.9/share/guile/site" "/gnu/store/mfkz7fvlfpv3ppwbkv0imb19nrf95akf-guile-3.0.9/share/guile")

```

However, that path is not in Emacs' own environment, as I can see with getenv:

``` ielm

ELISP> (getenv "GUILE_LOAD_PATH")

"/home/christopher/.guix-home/profile/share/guile/site/3.0:/home/christopher/.guix-profile/share/guile/site/3.0:/run/current-system/profile/share/guile/site/3.0"

ELISP> (getenv "GUILE_LOAD_COMPILED_PATH")

"/home/christopher/.guix-home/profile/lib/guile/3.0/site-ccache:/home/christopher/.guix-home/profile/share/guile/site/3.0:/home/christopher/.guix-profile/lib/guile/3.0/site-ccache:/home/christopher/.guix-profile/share/guile/site/3.0:/run/current-system/profile/lib/guile/3.0/site-ccache:/run/current-system/profile/share/guile/site/3.0"

```

So, my experiment was to see if I could run the scheme command «(guix-command "pull")» from the console instead, just using guix repl. However, since guix repl will not load any emacs-guix scheme code, I had to add "/home/christopher/Repos/emacs-guix/scheme" to the GUILE_LOAD_PATH in order to be able to load (emacs-guix) module.

Hopefully that clarifies what I am seeing.

Looking at this now, I see that there are significant differences between the paths for paths in %load-path vs paths in GUILE_LOAD_PATH. Perhaps I am running old code from the wrong profile or something. I will try to look into this more.

``` eshell

~/Repos/guix $ realpath /home/christopher/.guix-home/profile/share/guile/site/3.0

/gnu/store/0zhhnwmk8jlvx2rycgkh6dclv75gp1xr-profile/share/guile/site/3.0

~/Repos/guix $ realpath "/home/christopher/.config/guix/current/share/guile/site/3.0"

/gnu/store/yqsx2n66a0hlzpimqsw392x8f2x6nrzi-guix-804f8b209-modules/share/guile/site/3.0

```

--

Christopher Howard

Christopher Howard <christopher@librehacker.com> writes:

I see. Thank you for clarifying.

Yes.

The "guix-module-union" entry I alluded to was one of the differences I

had observed between %load-path values between "guile" and "guix repl"

when both were invoked from the commandline (outside of Emacs). It may

help for a future version of emacs-guix to take some steps to resolve

said differences, if you find them to be material / problematic.

--

Suhail

After cleaning up my profiles, and some other troubleshooting, I eventually realized that the failure can be bypassed by setting guix-repl-use-server to nil, i.e., disabling emacs-guix from using the additional Internal REPL (#<buffer *Guix\ Internal\ REPL*>).

The Internal REPL gave me trouble in another bug as well. I'll need to try to get a better understanding of how the magic of the Internal REPL works and how it could be messing this up.

--

Christopher Howard