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

[Liam Hupfer]

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