[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Janneke Nieuwenhuizen]

* etc/guix-install.sh (GUILE_LOAD_PATH): Prepend directory to current Guix
modules.
(GUILE_LOAD_COMPILED_PATH): Likewise to compiled modules.

Change-Id: I0b2722a38b1f8ebab32142cbc372a23cadfb0620
---
 etc/guix-install.sh | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/etc/guix-install.sh b/etc/guix-install.sh
index 982fb0a266..a0bb3a556b 100755
--- a/etc/guix-install.sh
+++ b/etc/guix-install.sh
@@ -12,6 +12,7 @@
 # Copyright © 2021, 2022, 2023 Maxim Cournoyer <maxim.cournoyer@gmail.com>
 # Copyright © 2022 Prafulla Giri <prafulla.giri@protonmail.com>
 # Copyright © 2023 Andrew Tropin <andrew@trop.in>
+# Copyright © 2024 Janneke Nieuwenhuizen <janneke@gnu.org>
 #
 # This file is part of GNU Guix.
 #
@@ -557,6 +558,10 @@ GUIX_LOCPATH="$GUIX_PROFILE/lib/locale:${GUIX_LOCPATH:+:}$GUIX_LOCPATH"
 
 export GUIX_LOCPATH
 
+# Make Guix modules available
+export GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
+export GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"
+
 EOF
 }
 

base-commit: 21f5d20d68e0359f8111ccb936905649c70db9c1
-- 
2.41.0

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Ludovic Courtès]

Hello!

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

> * etc/guix-install.sh (GUILE_LOAD_PATH): Prepend directory to current Guix
> modules.
> (GUILE_LOAD_COMPILED_PATH): Likewise to compiled modules.
>
> Change-Id: I0b2722a38b1f8ebab32142cbc372a23cadfb0620

[...]

> @@ -557,6 +558,10 @@ GUIX_LOCPATH="$GUIX_PROFILE/lib/locale:${GUIX_LOCPATH:+:}$GUIX_LOCPATH"
>  
>  export GUIX_LOCPATH
>  
> +# Make Guix modules available
> +export GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
> +export GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"

My inclination would be to let people just use ‘guix repl’, but maybe
that’s not satisfactory or convenient?  WDYT?

Ludo’.

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hi,

> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>
>> * etc/guix-install.sh (GUILE_LOAD_PATH): Prepend directory to current Guix
>> modules.
>> (GUILE_LOAD_COMPILED_PATH): Likewise to compiled modules.

[..]

>> +# Make Guix modules available
>> +export GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
>> +export GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"
>
> My inclination would be to let people just use ‘guix repl’, but maybe
> that’s not satisfactory or convenient?  WDYT?

The intention is to have the foreign distro experience resemble Guix
System more, esp. for newbee users.  If you have a code base that uses
Guix modules and comes with a guix.scm, running "guix shell" doesn't
work for them.  Unless, maybe, you add "guix" to the package's
native-inputs -- yuck.

They'd have to probably do something guix time-machine --channel=xxx to
get access to guix modules.  That, or source a script that set the
environment variables, which is what we let them do currently.  I was
guessing "everyone" is probably fighting with this, so finally decided
to upstream it :)

If there's a better/easier solution for this, I'm all ears!

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Ludovic Courtès]

Hi,

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

>>> +# Make Guix modules available
>>> +export GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
>>> +export GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"
>>
>> My inclination would be to let people just use ‘guix repl’, but maybe
>> that’s not satisfactory or convenient?  WDYT?
>
> The intention is to have the foreign distro experience resemble Guix
> System more, esp. for newbee users.  If you have a code base that uses
> Guix modules and comes with a guix.scm, running "guix shell" doesn't
> work for them.  Unless, maybe, you add "guix" to the package's
> native-inputs -- yuck.

Packages that extend Guix functionality, like Cuirass and hpcguix-web,
have ‘guix’ in their inputs.  That’s fine: they use just the core (guix …)
modules to interact with the store etc.

Is that what the kind of use case you had in mind?

> They'd have to probably do something guix time-machine --channel=xxx to
> get access to guix modules.  That, or source a script that set the
> environment variables, which is what we let them do currently.  I was
> guessing "everyone" is probably fighting with this, so finally decided
> to upstream it :)
>
> If there's a better/easier solution for this, I'm all ears!

I don’t think one needs ‘guix time-machine’; ‘guix repl’ is enough to
get access to Guix modules.

But maybe I’m missing something?

Thanks,
Ludo’.

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hello,

> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>
>>>> +# Make Guix modules available
>>>> +export
>>>> GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
>>>> +export
>>>> GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"
>>>
>>> My inclination would be to let people just use ‘guix repl’, but maybe
>>> that’s not satisfactory or convenient?  WDYT?
>>
>> The intention is to have the foreign distro experience resemble Guix
>> System more, esp. for newbee users.  If you have a code base that uses
>> Guix modules and comes with a guix.scm, running "guix shell" doesn't
>> work for them.  Unless, maybe, you add "guix" to the package's
>> native-inputs -- yuck.
>
> Packages that extend Guix functionality, like Cuirass and hpcguix-web,
> have ‘guix’ in their inputs.  That’s fine: they use just the core (guix …)
> modules to interact with the store etc.
>
> Is that what the kind of use case you had in mind?

Yes.  I always believed this was a big no-no, but adding guix to the
packages' inputs in guix.scm would also work.

>> They'd have to probably do something guix time-machine --channel=xxx to
>> get access to guix modules.  That, or source a script that set the
>> environment variables, which is what we let them do currently.  I was
>> guessing "everyone" is probably fighting with this, so finally decided
>> to upstream it :)
>>
>> If there's a better/easier solution for this, I'm all ears!
>
> I don’t think one needs ‘guix time-machine’; ‘guix repl’ is enough to
> get access to Guix modules.

Yeah, but as stated above, it was to setup a (configure) shell, so...

I'm still somewhat puzzled about why setting GUILE_LOAD[_COMPILED]_PATH
would be a bad idea, but unless someone else decides to chimes some time
soon in I guess we can close this bug.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Ludovic Courtès]

Janneke Nieuwenhuizen <janneke@gnu.org> skribis:

>> Packages that extend Guix functionality, like Cuirass and hpcguix-web,
>> have ‘guix’ in their inputs.  That’s fine: they use just the core (guix …)
>> modules to interact with the store etc.
>>
>> Is that what the kind of use case you had in mind?
>
> Yes.  I always believed this was a big no-no, but adding guix to the
> packages' inputs in guix.scm would also work.

Yes, and it’s even unavoidable for software that depends on (guix …)
modules.

> I'm still somewhat puzzled about why setting GUILE_LOAD[_COMPILED]_PATH
> would be a bad idea, but unless someone else decides to chimes some time
> soon in I guess we can close this bug.

It’s not too bad, but (1) it could break the user’s setup (for instance
if they’ve installed some incompatible Guile versions via the host
distro and all of a sudden Guile 3.0.9 modules show up in the search
path), and (2) one could just as well consider special-casing ‘CPATH’ or
‘GUIX_PYTHONPATH’.

So I think we can close, but again, if I misunderstood how the status
quo is a hindrance, I’m open to this change or any other solution.

Ludo’.

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Maxim Cournoyer]

Hi Ludo,

Ludovic Courtès <ludo@gnu.org> writes:

> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>
>>> Packages that extend Guix functionality, like Cuirass and hpcguix-web,
>>> have ‘guix’ in their inputs.  That’s fine: they use just the core (guix …)
>>> modules to interact with the store etc.
>>>
>>> Is that what the kind of use case you had in mind?
>>
>> Yes.  I always believed this was a big no-no, but adding guix to the
>> packages' inputs in guix.scm would also work.
>
> Yes, and it’s even unavoidable for software that depends on (guix …)
> modules.
>
>> I'm still somewhat puzzled about why setting GUILE_LOAD[_COMPILED]_PATH
>> would be a bad idea, but unless someone else decides to chimes some time
>> soon in I guess we can close this bug.
>
> It’s not too bad, but (1) it could break the user’s setup (for instance
> if they’ve installed some incompatible Guile versions via the host
> distro and all of a sudden Guile 3.0.9 modules show up in the search
> path), and (2) one could just as well consider special-casing ‘CPATH’ or
> ‘GUIX_PYTHONPATH’.

It wouldn't break the user setup; it'd just means perhaps the
Guix-provided modules wouldn't work with their Guile version, right?

The thing is that on Guix System, guix modules happen to be readily
available, because the guix-daemon pulls Guix in the system profile,
IIUC.  That they are not on a foreign system is confusing and can lead
to problems (I got bit by that while adding support for Guix in Guile
Hall [0]).

About 2), exposing CPATH or GUIX_PYTHONPATH doesn't make sense as we
aren't shipping C or Python libraries while we do ship a Guile API :-).

[0]  https://gitlab.com/a-sassmannshausen/guile-hall/-/issues/85#note_1769942699

> So I think we can close, but again, if I misunderstood how the status
> quo is a hindrance, I’m open to this change or any other solution.

I don't quite like the status quo where Guix System is different from
Guix on a foreign distribution for dubious reasons.  Either we expose
the Guix modules as part of the guix-install.sh or perhaps we can avoid
exposing them on Guix System, for consistency.

What do you think?

-- 
Thanks,
Maxim

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Ludovic Courtès]

Hi,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:

[...]

>>> I'm still somewhat puzzled about why setting GUILE_LOAD[_COMPILED]_PATH
>>> would be a bad idea, but unless someone else decides to chimes some time
>>> soon in I guess we can close this bug.
>>
>> It’s not too bad, but (1) it could break the user’s setup (for instance
>> if they’ve installed some incompatible Guile versions via the host
>> distro and all of a sudden Guile 3.0.9 modules show up in the search
>> path), and (2) one could just as well consider special-casing ‘CPATH’ or
>> ‘GUIX_PYTHONPATH’.

[...]

>> So I think we can close, but again, if I misunderstood how the status
>> quo is a hindrance, I’m open to this change or any other solution.
>
> I don't quite like the status quo where Guix System is different from
> Guix on a foreign distribution for dubious reasons.  Either we expose
> the Guix modules as part of the guix-install.sh or perhaps we can avoid
> exposing them on Guix System, for consistency.
>
> What do you think?

Sorry for the delay.  It’s probably not that big a deal so if you think
this improves user experience, go for it; I don’t want to block this
change.  Worst that can happen is we change our mind and revert it,
that’s OK.

Ludo’.

bug#68498: [PATCH] guix-install.sh: Make Guix modules available too.

[Janneke Nieuwenhuizen]

Ludovic Courtès writes:

Hi,

> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
[..]
>> I don't quite like the status quo where Guix System is different from
>> Guix on a foreign distribution for dubious reasons.  Either we expose
>> the Guix modules as part of the guix-install.sh or perhaps we can avoid
>> exposing them on Guix System, for consistency.
>>
>> What do you think?
>
> Sorry for the delay.  It’s probably not that big a deal so if you think
> this improves user experience, go for it; I don’t want to block this
> change.  Worst that can happen is we change our mind and revert it,
> that’s OK.

"Great".  I was very much in favor of this change initially: Have a
consistent Guix UX whether it be in Guix System or on a foreign distro.

Ludovic convinced me it might adverely affect the UX of the foreign
system, so yeah, I also don't know.

Most users that install Guix on a foreign system might be converting to
Guix and look for more Guix consistancy, or they might.

Let's have the universe tell us what it thinks.  We tried the current
situation and it's not great.

Pushe to master as 78390634d76c0c75c6e93742fa7caec965194641.

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Janneke Nieuwenhuizen]

Janneke Nieuwenhuizen writes:

Hello,

>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
> [..]
>>> I don't quite like the status quo where Guix System is different from
>>> Guix on a foreign distribution for dubious reasons.  Either we expose
>>> the Guix modules as part of the guix-install.sh or perhaps we can avoid
>>> exposing them on Guix System, for consistency.
>>>
>>> What do you think?
>>
>> Sorry for the delay.  It’s probably not that big a deal so if you think
>> this improves user experience, go for it; I don’t want to block this
>> change.  Worst that can happen is we change our mind and revert it,
>> that’s OK.
>
> "Great".  I was very much in favor of this change initially: Have a
> consistent Guix UX whether it be in Guix System or on a foreign distro.

[..]

Nice as it is that on Guix System you have Guix' modules available to
Guile by default, I stumbled onto another (obvious?) UX issue.

After doing `guix pull' (and no guix system reconfigure), you have a new
guix!  With new modules.  You can play with them in `guix repl'.  Only,
when you start the guile, these new modules are not available; guile can
only see the (stale) system's guix modules.  I'm not even sure how to
make them available to guile, other than `guix system reconfigure'.

"guix shell guile" doesn't make guix's modules available, of course, and
"guix shell guix guile will get you the previous guix, not the new
version made available by pull.  The only thing I could think of, is to
provide a `guile' binary in ~/.config/guix/current/bin/guile.  Hmm.

Hopefully there's an easier solution but if we cannot (or don't want to)
change/fix this, I'd possibly even rather not have guix modules
available to guile by default.  WDYT?

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Maxim Cournoyer]

Hi Janneke,

Janneke Nieuwenhuizen <janneke@gnu.org> writes:

> Janneke Nieuwenhuizen writes:
>
> Hello,
>
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>
>>>> Ludovic Courtès <ludo@gnu.org> writes:
>> [..]
>>>> I don't quite like the status quo where Guix System is different from
>>>> Guix on a foreign distribution for dubious reasons.  Either we expose
>>>> the Guix modules as part of the guix-install.sh or perhaps we can avoid
>>>> exposing them on Guix System, for consistency.
>>>>
>>>> What do you think?
>>>
>>> Sorry for the delay.  It’s probably not that big a deal so if you think
>>> this improves user experience, go for it; I don’t want to block this
>>> change.  Worst that can happen is we change our mind and revert it,
>>> that’s OK.
>>
>> "Great".  I was very much in favor of this change initially: Have a
>> consistent Guix UX whether it be in Guix System or on a foreign distro.
>
> [..]
>
> Nice as it is that on Guix System you have Guix' modules available to
> Guile by default, I stumbled onto another (obvious?) UX issue.

> After doing `guix pull' (and no guix system reconfigure), you have a new
> guix!  With new modules.  You can play with them in `guix repl'.  Only,
> when you start the guile, these new modules are not available; guile can
> only see the (stale) system's guix modules.  I'm not even sure how to
> make them available to guile, other than `guix system reconfigure'.

Even then, the modules available are not that of the latest pulled Guix;
they are those of the guix package known by that guix, which was used to
run the guix-daemon service.

> "guix shell guile" doesn't make guix's modules available, of course, and
> "guix shell guix guile will get you the previous guix, not the new
> version made available by pull.  The only thing I could think of, is to
> provide a `guile' binary in ~/.config/guix/current/bin/guile.  Hmm.

I'm not sure how providing a Guile from there would help?

> Hopefully there's an easier solution but if we cannot (or don't want to)
> change/fix this, I'd possibly even rather not have guix modules
> available to guile by default.  WDYT?

Perhaps we should treat the Guix library as a first class citizen, and
expose them to the Guile load path by default?  This would need to be
done in some config file such as .bashrc, and could be automated in the
guix-install. script, I believe.

If we do this, we should also change the guix-daemon-service-type to
avoid leaking 'guix' into the system profile, polluting it with old
modules.

What do you think?  Is there a better alternative I do not see?

-- 
Thanks,
Maxim

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Janneke Nieuwenhuizen]

Maxim Cournoyer writes:

Hi Maxim,

> Janneke Nieuwenhuizen <janneke@gnu.org> writes:
>
>> Janneke Nieuwenhuizen writes:
>>
>> Hello,
>>
>>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>>
>>>>> Ludovic Courtès <ludo@gnu.org> writes:
[..]

>> Nice as it is that on Guix System you have Guix' modules available to
>> Guile by default, I stumbled onto another (obvious?) UX issue.
>
>> After doing `guix pull' (and no guix system reconfigure), you have a new
>> guix!  With new modules.  You can play with them in `guix repl'.  Only,
>> when you start the guile, these new modules are not available; guile can
>> only see the (stale) system's guix modules.  I'm not even sure how to
>> make them available to guile, other than `guix system reconfigure'.
>
> Even then, the modules available are not that of the latest pulled Guix;
> they are those of the guix package known by that guix, which was used to
> run the guix-daemon service.

Ah, right.  They're only available to ~/.config/guix/current/bin/guix,
and thus also to its repl.

>> "guix shell guile" doesn't make guix's modules available, of course, and
>> "guix shell guix guile will get you the previous guix, not the new
>> version made available by pull.  The only thing I could think of, is to
>> provide a `guile' binary in ~/.config/guix/current/bin/guile.  Hmm.
>
> I'm not sure how providing a Guile from there would help?

Maybe I'm confusing things.  Guile will only set its GUILE_*_LOAD_PATHS
if installed in the same profile; I thought the toplevel `guile' we
build in guix is a hack to do just that.  But I'm a bit out of my depth
here.

>> Hopefully there's an easier solution but if we cannot (or don't want to)
>> change/fix this, I'd possibly even rather not have guix modules
>> available to guile by default.  WDYT?
>
> Perhaps we should treat the Guix library as a first class citizen, and
> expose them to the Guile load path by default?  This would need to be
> done in some config file such as .bashrc, and could be automated in the
> guix-install. script, I believe.

That would be nice, I think.

> If we do this, we should also change the guix-daemon-service-type to
> avoid leaking 'guix' into the system profile, polluting it with old
> modules.
>
> What do you think?  Is there a better alternative I do not see?

Good questions, who would know such things? ;)

Greetings,
Janneke

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Liam Hupfer via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 3367 bytes --]

Hi all,

I’m new to Guix and ran into the load path issue on foreign distros.

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Ludovic Courtès <ludo@gnu.org> writes:
>
>> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>>
>>> I’m still somewhat puzzled about why setting GUILE_LOAD[_COMPILED]_PATH
>>> would be a bad idea, but unless someone else decides to chimes some time
>>> soon in I guess we can close this bug.
>>
>> It’s not too bad, but (1) it could break the user’s setup (for instance
>> if they’ve installed some incompatible Guile versions via the host
>> distro and all of a sudden Guile 3.0.9 modules show up in the search
>> path), and (2) one could just as well consider special-casing ‘CPATH’ or
>> ‘GUIX_PYTHONPATH’.

I tend to agree. We should avoid adding to the global environment in a
default Guix installation as much as possible.

> About 2), exposing CPATH or GUIX_PYTHONPATH doesn’t make sense as we
> aren’t shipping C or Python libraries while we do ship a Guile API :-).

Agreed, but GUILE_LOAD{,_COMPILED}_PATH are set appropriately when guix
and guile are installed in a profile. IMO we should keep the global
environment clean and encourage installing guix in a profile (or
exporting the Guile variables on a per-project basis via something like
direnv) for users who want to hack on Guix configs.

>> So I think we can close, but again, if I misunderstood how the status
>> quo is a hindrance, I’m open to this change or any other solution.
>
> I don’t quite like the status quo where Guix System is different from
> Guix on a foreign distribution for dubious reasons.  Either we expose
> the Guix modules as part of the guix-install.sh or perhaps we can avoid
> exposing them on Guix System, for consistency.

I agree that this inconsistency isn’t great. I’m starting to use Guix on
a foreign distro (NixOS) and the Guix docs gave me pointers to Geiser,
but new Guix users who are also new to Guile just find themselves with a
lot of cryptic errors when hacking on their Guix configuration until
they figure out they need to add the Guix modules to the Guile load
paths. That’s what led me to this bug. For what it’s worth, I think the
latter approach is better—the default Guix System environment should be
as tidy as possible.

Looks like the patch was applied, but I would advocate for just
documenting this better in “The Perfect Setup” and other related
sections of the documentation. We can list the lines Janneke added to
guix-install.sh there and users can add them to their .profile,
project-level .envrc, or whatever they prefer.

It’s worth noting as well that more and more distros are providing
“native” Guix packages that may not use guix-install.sh at all. NixOS
does, for instance. Vagrant’s Debian package looks like it tries to sync
[its profile.d script] with the one from guix-install, but if so, it’s
currently outdated and lacks the Guile path variables. So even if we
don’t revert the patch (and don’t fix Guix System to not expose the Guix
modules), updating the documentation would still be useful to users
consuming foreign Guix packages.

—Liam


[its profile.d script] <https://salsa.debian.org/debian/guix/-/blob/b1d0628cbedea22f175a463f4c4935d02601bf93/debian/guix.sh>

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Maxim Cournoyer]

Hi Liam,

Liam Hupfer <liam@hpfr.net> writes:

> Hi all,
>
> I’m new to Guix and ran into the load path issue on foreign distros.
>
> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>
>> Ludovic Courtès <ludo@gnu.org> writes:
>>
>>> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>>>
>>>> I’m still somewhat puzzled about why setting GUILE_LOAD[_COMPILED]_PATH
>>>> would be a bad idea, but unless someone else decides to chimes some time
>>>> soon in I guess we can close this bug.
>>>
>>> It’s not too bad, but (1) it could break the user’s setup (for instance
>>> if they’ve installed some incompatible Guile versions via the host
>>> distro and all of a sudden Guile 3.0.9 modules show up in the search
>>> path), and (2) one could just as well consider special-casing ‘CPATH’ or
>>> ‘GUIX_PYTHONPATH’.
>
> I tend to agree. We should avoid adding to the global environment in a
> default Guix installation as much as possible.
>
>> About 2), exposing CPATH or GUIX_PYTHONPATH doesn’t make sense as we
>> aren’t shipping C or Python libraries while we do ship a Guile API :-).
>
> Agreed, but GUILE_LOAD{,_COMPILED}_PATH are set appropriately when guix
> and guile are installed in a profile. IMO we should keep the global
> environment clean and encourage installing guix in a profile (or
> exporting the Guile variables on a per-project basis via something like
> direnv) for users who want to hack on Guix configs.

Guix is essentially "installed by default" in the system profile or in
your user profile; it'd make sense to expose its matching library (Guile
modules) to me.  Note that the workaround of installing 'guix'
explicitly with 'guix install guix' will cause your guix to downgrade
itself on every 'guix pull', making it a non-solution.

Thanks for sharing your input.  It looks like on Guix System we could
extend the /etc/profile skeleton in (gnu system) to extend the
GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH with the entries from the
user and guix current profiles, around this bit:

--8<---------------cut here---------------start------------->8---
# Arrange so that ~/.config/guix/current comes first.
for profile in \"$HOME/.guix-profile\" \"$HOME/.config/guix/current\"
do
  if [ -f \"$profile/etc/profile\" ]
  then
    # Load the user profile's settings.
    GUIX_PROFILE=\"$profile\" ; \\
    . \"$profile/etc/profile\"
  else
    # At least define this one so that basic things just work
    # when the user installs their first package.
    export PATH=\"$profile/bin:$PATH\"
  fi
done
--8<---------------cut here---------------end--------------->8---

We'd have to come up with an equivalent for guix-install.sh; I think it
could go to the /etc/profile.d/guix.sh file we create.

On top of that, we'd have to review the guix-daemon-service-type and
modify it so that it no longer propagates a 'guix' package to the system
profile.

Does that sound like a good way forward?

-- 
Thanks,
Maxim

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Liam Hupfer via Guix-patches via]

[-- Attachment #1: Type: text/plain, Size: 2749 bytes --]

Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:

> Liam Hupfer <liam@hpfr.net> writes:
>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>>> About 2), exposing CPATH or GUIX_PYTHONPATH doesn’t make sense as we
>>> aren’t shipping C or Python libraries while we do ship a Guile API :-).
>>
>> Agreed, but GUILE_LOAD{,_COMPILED}_PATH are set appropriately when guix
>> and guile are installed in a profile. IMO we should keep the global
>> environment clean and encourage installing guix in a profile (or
>> exporting the Guile variables on a per-project basis via something like
>> direnv) for users who want to hack on Guix configs.
>
> Guix is essentially “installed by default” in the system profile or in
> your user profile; it’d make sense to expose its matching library (Guile
> modules) to me.

I see where you’re coming from, but I guess in my mind the Guile modules
could be considered a “developer interface” that needn’t be globally
exposed to all users. Of course it probably makes sense for the
overwhelming majority of Guix users today, but I’m thinking more
theoretically, e.g. a sysadmin providing a Linux server to multiple
unprivileged users who don’t need to know or care what distribution is
running. For those users, these variables are just clutter, extra
`printenv' noise.

> Note that the workaround of installing ’guix’ explicitly with ’guix
> install guix’ will cause your guix to downgrade itself on every ’guix
> pull’, making it a non-solution.

Good point.

> Thanks for sharing your input. It looks like on Guix System we could
> extend the /etc/profile skeleton in (gnu system) to extend the
> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH with the entries from the
> user and guix current profiles, around this bit:

> We’d have to come up with an equivalent for guix-install.sh; I think
> it could go to the /etc/profile.d/guix.sh file we create.
>
> On top of that, we’d have to review the guix-daemon-service-type and
> modify it so that it no longer propagates a ’guix’ package to the
> system profile.
>
> Does that sound like a good way forward?

That sounds like an improvement over the current situation, though I’m
still not fond of defining these at the session level, even with
prepending the user-level `~/.config/guix/current' to ensure things work
after `guix pull'. I would rather just mention this approach in the
documentation. Regardless, I suppose they’re easy enough to unset via
`.profile'. As much as I prefer my hermetic environment, it’s probably
more practical to set them to avoid bug reports from users who didn’t
make it through every line of the documentation.

—Liam

[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.

[Janneke Nieuwenhuizen]

Maxim Cournoyer writes:

Hi!

> Liam Hupfer <liam@hpfr.net> writes:
>
>> Hi all,
>>
>> I’m new to Guix and ran into the load path issue on foreign distros.
>>
>> Maxim Cournoyer <maxim.cournoyer@gmail.com> writes:
>>
>>> Ludovic Courtès <ludo@gnu.org> writes:
>>>
>>>> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>>>>
>>>>> I’m still somewhat puzzled about why setting GUILE_LOAD[_COMPILED]_PATH
>>>>> would be a bad idea, but unless someone else decides to chimes some time
>>>>> soon in I guess we can close this bug.
>>>>
>>>> It’s not too bad, but (1) it could break the user’s setup (for instance
>>>> if they’ve installed some incompatible Guile versions via the host
>>>> distro and all of a sudden Guile 3.0.9 modules show up in the search
>>>> path), and (2) one could just as well consider special-casing ‘CPATH’ or
>>>> ‘GUIX_PYTHONPATH’.
>>
>> I tend to agree. We should avoid adding to the global environment in a
>> default Guix installation as much as possible.
>>
>>> About 2), exposing CPATH or GUIX_PYTHONPATH doesn’t make sense as we
>>> aren’t shipping C or Python libraries while we do ship a Guile API :-).
>>
>> Agreed, but GUILE_LOAD{,_COMPILED}_PATH are set appropriately when guix
>> and guile are installed in a profile. IMO we should keep the global
>> environment clean and encourage installing guix in a profile (or
>> exporting the Guile variables on a per-project basis via something like
>> direnv) for users who want to hack on Guix configs.
>
> Guix is essentially "installed by default" in the system profile or in
> your user profile; it'd make sense to expose its matching library (Guile
> modules) to me.  Note that the workaround of installing 'guix'
> explicitly with 'guix install guix' will cause your guix to downgrade
> itself on every 'guix pull', making it a non-solution.
>
> Thanks for sharing your input.  It looks like on Guix System we could
> extend the /etc/profile skeleton in (gnu system) to extend the
> GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH with the entries from the
> user and guix current profiles, around this bit:
>
> # Arrange so that ~/.config/guix/current comes first.
> for profile in \"$HOME/.guix-profile\" \"$HOME/.config/guix/current\"
> do
>   if [ -f \"$profile/etc/profile\" ]
>   then
>     # Load the user profile's settings.
>     GUIX_PROFILE=\"$profile\" ; \\
>     . \"$profile/etc/profile\"
>   else
>     # At least define this one so that basic things just work
>     # when the user installs their first package.
>     export PATH=\"$profile/bin:$PATH\"
>   fi
> done

This is nice, at I've added

    export GUILE_LOAD_PATH="$profile/share/guile/site/3.0\
${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH"
    export GUILE_LOAD_COMPILED_PATH="$profile/lib/guile/3.0/site-ccache\
${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH"

in my local installation right away and (obviously) now have Guix
modules available that match the newly pulled guix (with the new
guix-home-service-type).

> We'd have to come up with an equivalent for guix-install.sh; I think it
> could go to the /etc/profile.d/guix.sh file we create.

Sure, that's where this started :)

> On top of that, we'd have to review the guix-daemon-service-type and
> modify it so that it no longer propagates a 'guix' package to the system
> profile.
>
> Does that sound like a good way forward?

LGTM!

-- 
Janneke Nieuwenhuizen <janneke@gnu.org>  | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com