When logged as user, GUILE_LOAD_COMPILED_PATH points to the system cache instead of the user cache

  • Open
  • quality assurance status badge
Details
3 participants
  • Denis 'GNUtoo' Carikli
  • Liliana Marie Prikler
  • Maxime Devos
Owner
unassigned
Submitted by
Denis 'GNUtoo' Carikli
Severity
normal
D
D
Denis 'GNUtoo' Carikli wrote on 22 Dec 2021 01:16
(address . bug-guix@gnu.org)
20211222011647.2d41452f@primary_laptop
Attachment: file
From 579e613da312f288aa9b9aebd264794bb9586625 Mon Sep 17 00:00:00 2001
From: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
Date: Wed, 22 Dec 2021 00:45:28 +0100
Subject: [PATCH] gnu: system: $GUIX_PROFILE/etc/profile: Fix
GUILE_LOAD_COMPILED_PATH

* gnu/system.scm (operating-system-etc-service)[profile]: export
GUILE_LOAD_COMPILED_PATH

Signed-off-by: Denis 'GNUtoo' Carikli <GNUtoo@cyberdimension.org>
---
gnu/system.scm | 2 ++
1 file changed, 2 insertions(+)

Toggle diff (15 lines)
diff --git a/gnu/system.scm b/gnu/system.scm
index 088c62ddde..4dbdf1928e 100644
--- a/gnu/system.scm
+++ b/gnu/system.scm
@@ -987,6 +987,8 @@ (define* (operating-system-etc-service os)
# Allow GStreamer-based applications to find plugins.
export GST_PLUGIN_PATH=\"$HOME/.guix-profile/lib/gstreamer-1.0\"
+export GUILE_LOAD_COMPILED_PATH=\"$HOME/.config/guix/current/lib/guile/3.0/site-ccache:$HOME/.config/guix/current/share/guile/site/3.0\"
+
if [ -n \"$BASH_VERSION\" -a -f /etc/bashrc ]
then
# Load Bash-specific initialization code.
--
2.34.0
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmHCbm8ACgkQX138wUF3
4mOtHBAAiBoysdOusJSCbOj0B/JmmfN/FNbxCSFoE6/aqW+XbZmBXeq44n+TQiPO
C0dTgq86cQxVo02oZGzcEgz1NiI8+zC7eQp/7FPac+RArUoaYY9XazJQaU0zWNvZ
H3Nt1TJXY1ovC7YR3NFoDN3YglLNAtJMjERNA0SmPW7VQFYzgQ2gdRN5NXH3SRy/
3ZWqa8l8qu5IGxGsM0UQKEONdZgjoifsKyPob8ip3YK2fw1/s8FsZQ61Pjxcyawi
meUnCJDKA+d1/i/FZq18AQeVbFiksrHpAhkWDzqlM4oy6mC+A6u6Duhp/qfX6Py2
wSJUi/DM/yyEvAPw2aQJM6s+wuFGgy70I6skevZyn9adCxCYx1+oTYfwXYBMIsvR
8oe423WG6m4+r7lODIWAQbGMPYvvk/O6Foxkp4eHVAGcTJmha1/lKC1bih07YAWu
OFV3fQDv2m7p0GnogWqcuvRwJgzliNms2GakcsBXCcdBBlRSDqLQP6RviTFquZOr
LNOUJnMvZJgTXBLbV7vvEYOUq4bdRRNh5G9s8A9bqUHMzEe+R0AELMMKh4pdfRhN
xZtD9q0jEKqHCSI9zpYH2exMkzh/EojBIWouuvtxMSQAKwJDENQvHqIjZxijOwqi
Vjfp/F6tRqByS3FsuxbmnXtNGapEPcZHg+gjnAPemdbq4BFf4S8=
=f9UX
-----END PGP SIGNATURE-----


L
L
Liliana Marie Prikler wrote on 22 Dec 2021 08:57
7c94e1ff91741598e028d4e0f32dba8ee0b38026.camel@ist.tugraz.at
Hi Denis,

Am Mittwoch, dem 22.12.2021 um 01:16 +0100 schrieb Denis 'GNUtoo'
Carikli:
Toggle quote (49 lines)
> [A]s user GUILE_LOAD_COMPILED_PATH is somehow exported to system
> paths:
> > [gnutoo@primary_laptop ~]$ echo $GUILE_LOAD_COMPILED_PATH
> > /run/current-system/profile/lib/guile/3.0/site-ccache:/run/current-
> > system/profile/share/guile/site/3.0
>
> So if I instead set it to the right paths it works again:
> > [gnutoo@primary_laptop guix]$ export
> > GUILE_LOAD_COMPILED_PATH="/home/gnutoo/.config/guix/current/lib/guile
> > /3.0/site-
> > ccache:/home/gnutoo/.config/guix/current/share/guile/site/3.0"
> > [gnutoo@primary_laptop guix]$ guix package -i hello
> > The following package will be upgraded:
> >    hello (dependencies or package changed)
> >
> > nothing to be done
>
> 'GUILE_LOAD_COMPILED_PATH="" guix package -i hello' also works.
>
> In my case the issue is that having
> '/run/current-system/profile/lib/guile/3.0/site-ccache' in
> GUILE_LOAD_COMPILED_PATH makes it fail:
> > [gnutoo@primary_laptop guix]$ export
> > GUILE_LOAD_COMPILED_PATH=/run/current-
> > system/profile/lib/guile/3.0/site-ccache
> > [gnutoo@primary_laptop guix]$ guix package -i hello Backtrace:
> > In ice-9/boot-9.scm:
> >    222:29 19 (map1 (((gnu packages gnupg)) ((gnu packages golang))
> > …))
> [...]
>
> And apparently it fails just because it is in the path:
> > [gnutoo@primary_laptop guix]$ export
> > GUILE_LOAD_COMPILED_PATH="/home/gnutoo/.config/guix/current/lib/guile
> > /3.0/site-
> > ccache:/home/gnutoo/.config/guix/current/share/guile/site/3.0:/run/cu
> > rrent-system/profile/lib/guile/3.0/site-ccache"
> > [gnutoo@primary_laptop guix]$ guix package -i hello Backtrace:
> > In ice-9/boot-9.scm:
> >    222:29 19 (map1 (((gnu packages gnupg)) ((gnu packages golang))
> > …))
> [...]
>
> This behavior probably happens becuase the system guix wasn't updated
> with guix system reconfigure for some time, and that the user relies on
> the system guile cache.
>
> And as I understand from #guix on liberachat, I'm supposed to be able
> to not keep my user profile and my guix system in sync.
This is only true to some extent. The local guix command still relies
on things in the system, such as the guix daemon itself, so you ought
to keep it up to date.

GUILE_LOAD_PATH does not point to the system cache "instead of" the
user cache, it gets expanded via profiles as everything else. Since
Guix has a system-wide installation of guile-3.0-latest, the guile
paths get set. You should probably install Guile locally instead of
system-wide if you plan on having the two diverge farther.

Toggle quote (4 lines)
> Would the solution to that be to correctly export
> GUILE_LOAD_COMPILED_PATH in  ~/.guix-profile/etc/profile like it is
> done in the patch I attached (with an extra small modification in the
> commit message to mention the bug report)?
No. The Guix command as built by `guix pull' sets its own load path,
but respects system paths too. You can check by spawning a REPL:

scheme@(guix-user)> %load-path
$1 = ("/gnu/store/yi47s6iy3glwzimy3nch1h7c9hjzmyw8-guix-module-
union/share/guile/site/3.0"
"/gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-guile-
3.0.7/share/guile/3.0" "/gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-
guile-3.0.7/share/guile/3.0"
"/gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-guile-
3.0.7/share/guile/site/3.0"
"/gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-guile-
3.0.7/share/guile/site" "/gnu/store/3h3jn0745ngd87zp83k5smwhykxvdfgf-
guile-3.0.7/share/guile" "/run/current-
system/profile/share/guile/site/3.0")

Toggle quote (6 lines)
> Other commits fixing bugs in that same profile mentioned bug reports,
> so I assume that it's simplier to discuss the bug in a bug report
> than directly sending a patch to fix the issue.
>
> Note that I also didn't test the patch yet but I did test that export
> command.
For the record, guile has been a part of the system profile since
%base-packages were first defined, so if your load paths break, there
is probably a larger issue at hand. In this particular case, your
local guix profile ought to shadow anything that's in /run/current-
system, so I don't really get how the ABI match is triggered. Perhaps
you might want to debug that in a REPL.

Cheers
M
M
Maxime Devos wrote on 22 Dec 2021 11:29
Re: bug#52727: When logged as user, GUILE_LOAD_COMPILED_PATH points to the system cache instead of the user cache
ba240a0fae1d2f3a2e5cee0ca428171b7f0ef496.camel@telenet.be
Liliana Marie Prikler schreef op wo 22-12-2021 om 08:57 [+0100]:
Toggle quote (7 lines)
> For the record, guile has been a part of the system profile since
> %base-packages were first defined, so if your load paths break, there
> is probably a larger issue at hand.  In this particular case, your
> local guix profile ought to shadow anything that's in /run/current-
> system, so I don't really get how the ABI match is triggered.  Perhaps
> you might want to debug that in a REPL.

Maybe the system guix has a package module that does not exist in the
user guix, so guix tries to load the system package module instead of
the non-existing user package module?

Greetings,
Maxime
M
M
Maxime Devos wrote on 22 Dec 2021 11:32
8f566ce905caa66d70c201bc7cfbc07d52949b29.camel@telenet.be
Liliana Marie Prikler schreef op wo 22-12-2021 om 08:57 [+0100]:
Toggle quote (3 lines)
> No.  The Guix command as built by `guix pull' sets its own load path,
> but respects system paths too.  You can check by spawning a REPL: [...]

But are there any good reasons to respect $GUILE_LOAD{,_COMPILE}_PATH
at all? Usually, we use wrap-program etc. to set load paths (guile,
python, PATH or otherwise). Maybe guile-launcher can be modified to set
the load path instead of appending to it?

Greetings,
Maxime.
L
L
Liliana Marie Prikler wrote on 22 Dec 2021 12:03
c73c839f828f4761c3e6c1dc5bb3cc5a1e5215f6.camel@ist.tugraz.at
Am Mittwoch, dem 22.12.2021 um 11:32 +0100 schrieb Maxime Devos:
Toggle quote (9 lines)
> Liliana Marie Prikler schreef op wo 22-12-2021 om 08:57 [+0100]:
> > No.  The Guix command as built by `guix pull' sets its own load path,
> > but respects system paths too.  You can check by spawning a REPL:
> > [...]
>
> But are there any good reasons to respect $GUILE_LOAD{,_COMPILE}_PATH
> at all? Usually, we use wrap-program etc. to set load paths (guile,
> python, PATH or otherwise). Maybe guile-launcher can be modified to set
> the load path instead of appending to it?
IIUC the guix command does not particularly need to provide support for
multiple profiles, so we could isolate it. After all, extensions ought
to be installed in the user's (single) current-guix profile, no?
(Disregarding the use of guix environment/guix shell, of course.) Or
more accurately, GUIX_EXTENSIONS_PATH serves as a different escape
hatch.
D
D
Denis 'GNUtoo' Carikli wrote on 23 Dec 2021 08:31
(name . Maxime Devos)(address . maximedevos@telenet.be)
20211223083115.5bd27816@primary_laptop
On Wed, 22 Dec 2021 11:29:29 +0100
Maxime Devos <maximedevos@telenet.be> wrote:

Toggle quote (11 lines)
> Liliana Marie Prikler schreef op wo 22-12-2021 om 08:57 [+0100]:
> > For the record, guile has been a part of the system profile since
> > %base-packages were first defined, so if your load paths break,
> > there is probably a larger issue at hand.  In this particular case,
> > your local guix profile ought to shadow anything that's in
> > /run/current- system, so I don't really get how the ABI match is
> > triggered.  Perhaps you might want to debug that in a REPL.
>
> Maybe the system guix has a package module that does not exist in the
> user guix, so guix tries to load the system package module instead of
> the non-existing user package module?
In my system.scm (I attached it) I do have a package (fdm-git) that
doesn't exist elsewhere (because I need a patch that is upstream but
not in an fdm release yet).

Right now I can't test without fdm-git because when doing guix
system reconfigure, it tries to build guix but its tests fails. I'll
bugreport about that.

Denis.
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEeC+d2+Nrp/PU3kkGX138wUF34mMFAmHEJcMACgkQX138wUF3
4mPAfA//e99p9NkknjxCAhgj0KkNrzWDQRnYN1JLBDN22Y1Ct0dRc9vLMpXeAvMp
qGYcQA1Rwz+TDOY5oz7e6gKA3/jSCEEu33y23ki3QrrWwOxYfvwhLyJcSpYLW53f
vF774KSZCoZm0440Oc9Z8ZHnpr2vgn39bWJZ8puroPgoh5VxK6XKJeeFH4zMUXah
bOcc42w2GzGDSR84Y0YGOzf0kIoWgOfBZkjPmwWisnD1g13R14xgAcoPCtZkpTTf
VVmJc7hCMMwaHCTGQgdUYwnVqkGns4DYEMWUMi9kt8SEjsdsRkQshShC5l+9Fp0O
PbwvpImhfCzhgS4g1MJ9p/sEKhveA0RzMZ0wwlP/BQduY9FVqMB6tv0r2MynLPHr
h0JmVg3wKM7hVXCQJSzmN0vofkPcFzlZ3uoM2Q3vu+KBBzt+TkTUBFBvyG8Lvccd
x1HC4LCyVDtKFGWb9DdyRBoy94yEXFwoNERkckUUqQgoapFiQ9TTyw8MFxcWyAIi
ZO40QFVo1spJk2CuIY3FEViYve5DwK9kuLsdGv51AUZH07d4V5PtD/z3B/xK20Mp
6DxntVAKUr941WOLmS/K3xpnaKCPg3QmpwGpiMD7V80RR38NydJA959fWDCI3/vz
ZHl7oHS3Kct/IK4biRdxKcC1elyiIw7HG2qr/fzzu/IVF6ByMAQ=
=vc58
-----END PGP SIGNATURE-----


L
L
Liliana Marie Prikler wrote on 23 Dec 2021 09:22
(address . 52727@debbugs.gnu.org)
be938beedec5282155a4cee441879809ef1f2923.camel@ist.tugraz.at
Am Donnerstag, dem 23.12.2021 um 08:31 +0100 schrieb Denis 'GNUtoo'
Carikli:
Toggle quote (18 lines)
> On Wed, 22 Dec 2021 11:29:29 +0100
> Maxime Devos <maximedevos@telenet.be> wrote:
>
> > Liliana Marie Prikler schreef op wo 22-12-2021 om 08:57 [+0100]:
> > > For the record, guile has been a part of the system profile since
> > > %base-packages were first defined, so if your load paths break,
> > > there is probably a larger issue at hand.  In this particular
> > > case,
> > > your local guix profile ought to shadow anything that's in
> > > /run/current- system, so I don't really get how the ABI match is
> > > triggered.  Perhaps you might want to debug that in a REPL. 
> >
> > Maybe the system guix has a package module that does not exist in
> > the user guix, so guix tries to load the system package module
> > instead of the non-existing user package module?
> In my system.scm (I attached it) I do have a package (fdm-git) that
> doesn't exist elsewhere (because I need a patch that is upstream but
> not in an fdm release yet).
The only relevant package from your system.scm (in the context of this
problem) would be the guix package, but you're not even editing the
guix service so it'd be a file removed from guix upstream since you
last reconfigured.


Cheers
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 52727@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 52727
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch