Open trivialfis opened 5 years ago
I guess you meant MELPA! :)
I cannot reproduce. Did you just update the package or guix? Then the compiled file cache might be out of date.
Remove ~/.cache/guile/ccache
and your issue should go.
Yes, MELPA, thanks.
I cleared the cache, but it doesn't solve the problem, still failing to load those modules. Is it possible that this is caused by guile-gcrypt
?
Currently , guile-gcrypt
is in my profile. If I unset GUILE_LOAD_PATH
and GUILE_LOAD_COMPILED_PATH
, then the following error is generated in message buffer:
Starting Guix REPL ... [5 times] helm-M-x: Error in evaluating guile expression:
:17:23: In procedure module-lookup: Unbound variable: %max-returned-list-size Entering a new prompt. Type
,bt' for a backtrace or
,q' to continue. scheme@(emacs-guix) [1]>
And in REPL buffer:
scheme@(guile-user)> ,m (emacs-guix) While executing meta-command: no code for module (gcrypt hash) scheme@(guile-user)>
And if I remove guile-gcrypt
, the same error as above (removing those envs) is generated. I am not quite sure how this is supposed to work.
It might be worth mentioning that the unbound variable error also happens when emacs-guix installed from Guix.
In my experience, installing emacs-guix from both MELPA and emacs-guix can lead to those errors. Try using only one at a time.
That's on two different computers.
Hi, I believe this is caused by incorrect load path. In the guix wrapper (the file named guix-command
in ~/.config/guix/current/bin
), there are lots of (set! %load-path ... ). I tried to export these paths to GUILE_LOAD_PATH
in bash and run emacs inside that shell, everything works like a charm. In my case, the exported path is:
export GUILE_LOAD_PATH=$GUILE_LOAD_PATH:/gnu/store/qbzw2ygy1nq2h0nq6sl9cgg1c5mq5g8z-guile-gcrypt-0.1.0/share/guile/site/2.2:/gnu/store/c63g5242rs04ipx1zrkma9zxvs8782sj-gnutls-3.5.18/share/guile/site/2.2:/gnu/store/h9221hw01vx7a0dg279mmyjkl5r6n5fc-libtasn1-4.13/share/guile/site/2.2:/gnu/store/wxrprxdxs0xys5a2wg5hs4x8kcm9366k-libidn2-2.0.4/share/guile/site/2.2:/gnu/store/hawxlh69k0mad5rrv128cinz2svkaxv2-nettle-3.4/share/guile/site/2.2:/gnu/store/fxiwj2wpp11sif613axdax7gmwzsg6kp-zlib-1.2.11/share/guile/site/2.2:/gnu/store/sq5paxxwbhh8lr60gwkx2fvgijs9mcjj-gmp-6.1.2/share/guile/site/2.2:/gnu/store/17d2b12hcxph2m6hilqkv1wl8bm5w98i-guile-git-0.1.0/share/guile/site/2.2:/gnu/store/1aglyrvw57cbw4njc2q4blmbqin3r7k2-guile-bytestructures-1.0.3/share/guile/site/2.2:/gnu/store/sw3wxk3ylxd1kc2z4z4kb5191x9pf17n-guile-json-1.2.0/share/guile/site/2.2:/gnu/store/w7mbgbw223l0zq0m0g986840wvm1m3yk-guile-ssh-0.11.3/share/guile/site/2.2:/gnu/store/rjp81r0sgvix8cplfgqyhyhmyxxk35a6-guile-sqlite3-0.1.0/share/guile/site/2.2
Oops, sorry for the huge delay, I did not notice this issue :blush:
Unfortunately, I don't really know what to do about it.
Apparently, you are right: the problem is in missing guile modules in the load path. If I understand correctly, it happens only on foreign (non-GuixSD) distros. On GuixSD, 'guix' package and all its requirements are installed in the system profile, so they are visible globally, thus there is no need to configure load path.
But if 'guix' is not installed (and only "guix pull" is used), then there are no required guile modules available ("~/.config/guix/current/bin/guix" loads them directly from store as you see), so guile repl does not have access to these modules.
The above is only my guess, but if I am right, the only solution I see
is to install 'guix' and 'guile' into ~/.guix-profile
. This should
set GUILELOAD[COMPILED_]PATH (in ~/.guix-profile/etc/profile
), so in
theory, this workaround should fix this problem. Please report, if you
will try this workaround. Installing 'guix' in the user profile
shouldn't make any harm as it will be shadowed by "guix pull"-ed one
anyway.
Thank you.
Thanks for the reply. Please give me some time to think about it. I'm a little occupied by other stuffs.
Sure, take your time, no need to hurry
Hi, I installed guix and guile in my package profile, which indeed fixed the issue. But is there anything we can do to make guix's own profile more "normal"? In the sense the profile in .config acting like other fellow packages?
Thanks.
If guix would have a special environment file, then we could simply load it. But since this environment is "hardcoded" inside ~/.config/guix/current/bin/guix
file, I'm afraid the only fix (workaround rather) for this problem on Emacs-Guix side would be to extract the required path from there.
I don't like this solution, but well, it's better than nothing.
I'll let you know when this workaround will be implemented (probably, not very soon)
One very simple solution would be making guix a propagated-inputs
? But I'm more interested in modifying Guix itself. I will try looking at it later (probably, not very soon). :)
One very simple solution would be making guix a propagated-inputs?
Oh, indeed! I didn't think about it. You are right, this will be a simple workaround. Not sure, if people would like to see that Emacs-Guix propagates Guix into their profiles, though :-)
But I'm more interested in modifying Guix itself.
Hm, do you mean to make guix pull
install guile dependencies into ~/.config/guix/current
? This would also be a fix, I think.
Hm, do you mean to make
guix pull
install guile dependencies into~/.config/guix/current
? This would also be a fix, I think.
Yes. :)
I wrote:
If guix would have a special environment file, then we could simply load it. But since this environment is "hardcoded" inside
~/.config/guix/current/bin/guix
file, I'm afraid the only fix (workaround rather) for this problem on Emacs-Guix side would be to extract the required path from there.I don't like this solution, but well, it's better than nothing.
I'll let you know when this workaround will be implemented (probably, not very soon)
After looking more at this, I came to the conclusion that this workaround would be too unreliable. Extracting all those %load-path
s from the guix
script using elisp will be so horribly ugly, that I don't want to do it. Also I don't see a way to extract these paths with guile code. So I'm afraid a fix can come only from Guix itself, for example, if all the required guile modules will be installed into ~/.config/guix/current
as @trivialfis suggested.
I think this issue should stay opened until it will be resolved in one way or another.
I added a note with a workaround for this problem to README: https://github.com/alezost/guix.el#important-note-for-non-guixsd-users
Running
guix-all-packages
orguix-number-of-packages
(maybe other commands as well) produces the following warning in "Guix REPL", and the displayed total number of packages 1341, which is significantly less than actual number of packages.maplemelpa.Thanks :)