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

[Janneke Nieuwenhuizen <janneke@gnu.org>]

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