Konrad Hinsen (2020-03-31 20:25:02 +0200) wrote:
> I did some experiments in the Guix REPL created by emacs-guix, but
> I don't understand what's happening. Here I am exploring
> emacs-caps-lock, a package that I got with today's pull:
>
> scheme@(emacs-guix)> (%search-load-path "gnu/packages/emacs-xyz")
> $4 =
> "/home/hinsen/.config/guix/current/share/guile/site/3.0/gnu/packages/emacs-xyz.scm"
>
> Looks OK. Let's look at the module and its filename:
>
> scheme@(emacs-guix)> (resolve-module '(gnu packages emacs-xyz))
> $5 = #<directory (gnu packages emacs-xyz) 7fb01ffb3280>
> scheme@(emacs-guix)> (module-filename (resolve-module '(gnu packages
> emacs-xyz)))
> $6 = "gnu/packages/emacs-xyz.scm"
>
> A relative filename, but relative to what? Why isn't this an absolute
> one? As for the package:
>
> scheme@(emacs-guix)> (module-variable (resolve-module '(gnu packages
> emacs-xyz)) 'emacs-caps-lock)
> $7 = #f
>
> It's not in there (but it is in the source code). And now for the real
> surprise:
>
> scheme@(emacs-guix)> (reload-module (resolve-module '(gnu packages
> emacs-xyz)))
> $8 = #<directory (gnu packages emacs-xyz) 7fb01ffb3280>
> scheme@(emacs-guix)> (module-filename (resolve-module '(gnu packages
> emacs-xyz)))
> $9 =
> "/home/hinsen/.config/guix/current/share/guile/site/3.0/gnu/packages/emacs-xyz.scm"
> scheme@(emacs-guix)> (module-variable (resolve-module '(gnu packages
> emacs-xyz)) 'emacs-caps-lock)
> $10 = #<variable 7fb010e61210 value: #<package emacs-caps-lock@1.0
> /home/hinsen/.config/guix/current/share/guile/site/3.0/gnu/packages/emacs-xyz.scm:1745
> 7fb01398ef20>>
>
> What the heck has Guile been loading the first time???
Thanks Konrad for investigating this! After seeing your tests, I came back to
the `guix-repl-use-latest` variable. According to info:
> Set this variable to nil, if you don’t want to use the latest Guix code
> received with ‘guix pull’ command.
My variable is `t` as defined at emacs-guix's `guix-repl.el`. It is used in
the `guix-repl-guile-args` to set the command line args for Guile. According
to `ps` in my system, I see these arguments:
/gnu/store/…-guile-2.2.6/bin/guile --no-auto-compile \
-L /gnu/store/…-emacs-guix-0.5.2/share/guile/site/2.2 \
-C /gnu/store/…-emacs-guix-0.5.2/lib/guile/2.2/site-ccache \
-L /home/ivan/.config/guix/current/share/guile/site/3.0 \
-C /home/ivan/.config/guix/current/lib/guile/3.0/site-ccache \
-L /gnu/store/…-guix-1.0.1-14.c2f9ea2/share/guile/site/2.2 \
-C /gnu/store/…-guix-1.0.1-14.c2f9ea2/lib/guile/2.2/site-ccache \
--listen=/tmp/emacs-guix-…/repl-socket -q \
-L /gnu/store/…-emacs-geiser-0.11.2/share/geiser/guile/
Please note the `-L …-guix-1.0.1-14… -C …-guix-1.0.1-14…`, this is added in
the `guix-repl-guile-args` function from the value of the variable
`guix-config-guix-scheme-directory`, defined in emacs-guix's
`guix-build-config.el` as
`/gnu/store/…-guix-1.0.1-14.c2f9ea2/share/guile/site/2.2`.
If I run `guix package -s guix`, the version of the `guix` package (which I
assume is the same that I got after the last `guix pull`, but I may be wrong)
is `1.0.1-15…`.
I guess that the Guile binary and `…-guix-1.0.1-14…` coming from emacs-guix
are unavoidable, the issue may be whether the `.config/guix/current` paths are
really taking precedence over emacs-guix's hardwired ones.
Now, if I do `guix package -u guix emacs-guix emacs-magit OTHER_DEPS…`, run
Emacs and invoke the package list, `ps` shows:
/gnu/store/…-guile-2.2.6/bin/guile --no-auto-compile \
-L /gnu/store/…-emacs-guix-0.5.2/share/guile/site/2.2 \
-C /gnu/store/…-emacs-guix-0.5.2/lib/guile/2.2/site-ccache \
-L /home/ivan/.config/guix/current/share/guile/site/3.0 \
-C /home/ivan/.config/guix/current/lib/guile/3.0/site-ccache \
--listen=/tmp/emacs-guix-…/repl-socket -q \
-L /gnu/store/…-emacs-geiser-0.11.2/share/geiser/guile/
Please note that the hardwired Guix paths are no longer there. Now the
package list only shows `guix` and `emacs-magit` as "from the future" (why?),
and some "obsolete" packages, which is fine.
Maybe I should just `guix package -u` this time and check if the problem
repeats with the next pull…
Thanks again!
--
Ivan Vilata i Balaguer -- https://elvil.net/
