GNU bug report logs -
#68498
[PATCH] guix-install.sh: Make Guix modules available too.
Previous Next
Reported by: Janneke Nieuwenhuizen <janneke <at> gnu.org>
Date: Tue, 16 Jan 2024 08:28:02 UTC
Severity: normal
Tags: patch
Done: Janneke Nieuwenhuizen <janneke <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Maxim Cournoyer writes:
Hi!
> Liam Hupfer <liam <at> hpfr.net> writes:
>
>> Hi all,
>>
>> I’m new to Guix and ran into the load path issue on foreign distros.
>>
>> Maxim Cournoyer <maxim.cournoyer <at> gmail.com> writes:
>>
>>> Ludovic Courtès <ludo <at> gnu.org> writes:
>>>
>>>> Janneke Nieuwenhuizen <janneke <at> 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 <at> gnu.org> | GNU LilyPond https://LilyPond.org
Freelance IT https://www.JoyOfSource.com | Avatar® https://AvatarAcademy.com
This bug report was last modified 1 year and 33 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.