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

[Liam Hupfer]

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>