Re: Emacs not seeing newer packages after pull

[Ivan Vilata i Balaguer <ivan@selidor.net>]

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/