unofficial mirror of guix-patches@gnu.org 
 help / color / mirror / code / Atom feed
From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Liam Hupfer <liam@hpfr.net>
Cc: "Ludovic Courtès" <ludo@gnu.org>,
	68498@debbugs.gnu.org, "Janneke Nieuwenhuizen" <janneke@gnu.org>
Subject: [bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.
Date: Sat, 20 Apr 2024 17:28:02 -0400	[thread overview]
Message-ID: <87il0biv19.fsf@gmail.com> (raw)
In-Reply-To: <87o7a43du1.fsf@hpfr.net> (Liam Hupfer's message of "Fri, 19 Apr 2024 22:36:22 -0500")

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




  reply	other threads:[~2024-04-20 21:29 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-16  8:27 [bug#68498] [PATCH] guix-install.sh: Make Guix modules available too Janneke Nieuwenhuizen
2024-01-24 22:22 ` Ludovic Courtès
2024-01-25  8:00   ` Janneke Nieuwenhuizen
2024-01-29 11:22     ` Ludovic Courtès
2024-01-29 11:54       ` Janneke Nieuwenhuizen
2024-01-29 16:05         ` Ludovic Courtès
2024-03-10  1:14           ` Maxim Cournoyer
2024-04-02 15:26             ` Ludovic Courtès
2024-04-07 14:37               ` bug#68498: " Janneke Nieuwenhuizen
2024-04-18 19:03                 ` [bug#68498] " Janneke Nieuwenhuizen
2024-04-19 11:40                   ` Maxim Cournoyer
2024-04-19 14:58                     ` Janneke Nieuwenhuizen
2024-04-20  3:36             ` Liam Hupfer via Guix-patches via
2024-04-20 21:28               ` Maxim Cournoyer [this message]
2024-04-21  2:07                 ` Liam Hupfer via Guix-patches via
2024-04-21  6:15                 ` Janneke Nieuwenhuizen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87il0biv19.fsf@gmail.com \
    --to=maxim.cournoyer@gmail.com \
    --cc=68498@debbugs.gnu.org \
    --cc=janneke@gnu.org \
    --cc=liam@hpfr.net \
    --cc=ludo@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).