From: Maxim Cournoyer <maxim.cournoyer@gmail.com>
To: Janneke Nieuwenhuizen <janneke@gnu.org>
Cc: 68498-done@debbugs.gnu.org, "Ludovic Courtès" <ludo@gnu.org>,
68498@debbugs.gnu.org
Subject: [bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.
Date: Fri, 19 Apr 2024 07:40:08 -0400 [thread overview]
Message-ID: <877cgtmvhj.fsf@gmail.com> (raw)
In-Reply-To: <87r0f2qyrt.fsf@gnu.org> (Janneke Nieuwenhuizen's message of "Thu, 18 Apr 2024 21:03:18 +0200")
Hi Janneke,
Janneke Nieuwenhuizen <janneke@gnu.org> writes:
> Janneke Nieuwenhuizen writes:
>
> Hello,
>
>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:
>>>
>>>> Ludovic Courtès <ludo@gnu.org> writes:
>> [..]
>>>> 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.
>>>>
>>>> What do you think?
>>>
>>> Sorry for the delay. It’s probably not that big a deal so if you think
>>> this improves user experience, go for it; I don’t want to block this
>>> change. Worst that can happen is we change our mind and revert it,
>>> that’s OK.
>>
>> "Great". I was very much in favor of this change initially: Have a
>> consistent Guix UX whether it be in Guix System or on a foreign distro.
>
> [..]
>
> Nice as it is that on Guix System you have Guix' modules available to
> Guile by default, I stumbled onto another (obvious?) UX issue.
> After doing `guix pull' (and no guix system reconfigure), you have a new
> guix! With new modules. You can play with them in `guix repl'. Only,
> when you start the guile, these new modules are not available; guile can
> only see the (stale) system's guix modules. I'm not even sure how to
> make them available to guile, other than `guix system reconfigure'.
Even then, the modules available are not that of the latest pulled Guix;
they are those of the guix package known by that guix, which was used to
run the guix-daemon service.
> "guix shell guile" doesn't make guix's modules available, of course, and
> "guix shell guix guile will get you the previous guix, not the new
> version made available by pull. The only thing I could think of, is to
> provide a `guile' binary in ~/.config/guix/current/bin/guile. Hmm.
I'm not sure how providing a Guile from there would help?
> Hopefully there's an easier solution but if we cannot (or don't want to)
> change/fix this, I'd possibly even rather not have guix modules
> available to guile by default. WDYT?
Perhaps we should treat the Guix library as a first class citizen, and
expose them to the Guile load path by default? This would need to be
done in some config file such as .bashrc, and could be automated in the
guix-install. script, I believe.
If we do this, we should also change the guix-daemon-service-type to
avoid leaking 'guix' into the system profile, polluting it with old
modules.
What do you think? Is there a better alternative I do not see?
--
Thanks,
Maxim
next prev parent reply other threads:[~2024-04-19 11:41 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 [this message]
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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=877cgtmvhj.fsf@gmail.com \
--to=maxim.cournoyer@gmail.com \
--cc=68498-done@debbugs.gnu.org \
--cc=68498@debbugs.gnu.org \
--cc=janneke@gnu.org \
--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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.