[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.
From: |
Maxim Cournoyer |
Subject: |
[bug#68498] [PATCH] guix-install.sh: Make Guix modules available too. |
Date: |
Sat, 09 Mar 2024 20:14:55 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Hi Ludo,
Ludovic Courtès <ludo@gnu.org> writes:
> Janneke Nieuwenhuizen <janneke@gnu.org> skribis:
>
>>> Packages that extend Guix functionality, like Cuirass and hpcguix-web,
>>> have ‘guix’ in their inputs. That’s fine: they use just the core (guix …)
>>> modules to interact with the store etc.
>>>
>>> Is that what the kind of use case you had in mind?
>>
>> Yes. I always believed this was a big no-no, but adding guix to the
>> packages' inputs in guix.scm would also work.
>
> Yes, and it’s even unavoidable for software that depends on (guix …)
> modules.
>
>> 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’.
It wouldn't break the user setup; it'd just means perhaps the
Guix-provided modules wouldn't work with their Guile version, right?
The thing is that on Guix System, guix modules happen to be readily
available, because the guix-daemon pulls Guix in the system profile,
IIUC. That they are not on a foreign system is confusing and can lead
to problems (I got bit by that while adding support for Guix in Guile
Hall [0]).
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 :-).
[0] https://gitlab.com/a-sassmannshausen/guile-hall/-/issues/85#note_1769942699
> So I think we can close, but again, if I misunderstood how the status
> quo is a hindrance, I’m open to this change or any other solution.
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?
--
Thanks,
Maxim
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug#68498] [PATCH] guix-install.sh: Make Guix modules available too.,
Maxim Cournoyer <=