| Message ID | 4a2bb9d98d265b73932a57c9a9bd2fc920e3f035.1705393477.git.janneke@gnu.org |
|---|---|
| State | New |
| Headers | show |
| Series | [bug#68498] guix-install.sh: Make Guix modules available too. | expand |
Hello! Janneke Nieuwenhuizen <janneke@gnu.org> skribis: > * etc/guix-install.sh (GUILE_LOAD_PATH): Prepend directory to current Guix > modules. > (GUILE_LOAD_COMPILED_PATH): Likewise to compiled modules. > > Change-Id: I0b2722a38b1f8ebab32142cbc372a23cadfb0620 [...] > @@ -557,6 +558,10 @@ GUIX_LOCPATH="$GUIX_PROFILE/lib/locale:${GUIX_LOCPATH:+:}$GUIX_LOCPATH" > > export GUIX_LOCPATH > > +# Make Guix modules available > +export GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH" > +export GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH" My inclination would be to let people just use ‘guix repl’, but maybe that’s not satisfactory or convenient? WDYT? Ludo’.
Ludovic Courtès writes: Hi, > Janneke Nieuwenhuizen <janneke@gnu.org> skribis: > >> * etc/guix-install.sh (GUILE_LOAD_PATH): Prepend directory to current Guix >> modules. >> (GUILE_LOAD_COMPILED_PATH): Likewise to compiled modules. [..] >> +# Make Guix modules available >> +export GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH" >> +export GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH" > > My inclination would be to let people just use ‘guix repl’, but maybe > that’s not satisfactory or convenient? WDYT? The intention is to have the foreign distro experience resemble Guix System more, esp. for newbee users. If you have a code base that uses Guix modules and comes with a guix.scm, running "guix shell" doesn't work for them. Unless, maybe, you add "guix" to the package's native-inputs -- yuck. They'd have to probably do something guix time-machine --channel=xxx to get access to guix modules. That, or source a script that set the environment variables, which is what we let them do currently. I was guessing "everyone" is probably fighting with this, so finally decided to upstream it :) If there's a better/easier solution for this, I'm all ears! Greetings, Janneke
Hi, Janneke Nieuwenhuizen <janneke@gnu.org> skribis: >>> +# Make Guix modules available >>> +export GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH" >>> +export GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH" >> >> My inclination would be to let people just use ‘guix repl’, but maybe >> that’s not satisfactory or convenient? WDYT? > > The intention is to have the foreign distro experience resemble Guix > System more, esp. for newbee users. If you have a code base that uses > Guix modules and comes with a guix.scm, running "guix shell" doesn't > work for them. Unless, maybe, you add "guix" to the package's > native-inputs -- yuck. 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? > They'd have to probably do something guix time-machine --channel=xxx to > get access to guix modules. That, or source a script that set the > environment variables, which is what we let them do currently. I was > guessing "everyone" is probably fighting with this, so finally decided > to upstream it :) > > If there's a better/easier solution for this, I'm all ears! I don’t think one needs ‘guix time-machine’; ‘guix repl’ is enough to get access to Guix modules. But maybe I’m missing something? Thanks, Ludo’.
Ludovic Courtès writes: Hello, > Janneke Nieuwenhuizen <janneke@gnu.org> skribis: > >>>> +# Make Guix modules available >>>> +export >>>> GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH" >>>> +export >>>> GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH" >>> >>> My inclination would be to let people just use ‘guix repl’, but maybe >>> that’s not satisfactory or convenient? WDYT? >> >> The intention is to have the foreign distro experience resemble Guix >> System more, esp. for newbee users. If you have a code base that uses >> Guix modules and comes with a guix.scm, running "guix shell" doesn't >> work for them. Unless, maybe, you add "guix" to the package's >> native-inputs -- yuck. > > 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. >> They'd have to probably do something guix time-machine --channel=xxx to >> get access to guix modules. That, or source a script that set the >> environment variables, which is what we let them do currently. I was >> guessing "everyone" is probably fighting with this, so finally decided >> to upstream it :) >> >> If there's a better/easier solution for this, I'm all ears! > > I don’t think one needs ‘guix time-machine’; ‘guix repl’ is enough to > get access to Guix modules. Yeah, but as stated above, it was to setup a (configure) shell, so... 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. Greetings, Janneke
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’. 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. Ludo’.
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?
Hi, Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: > Ludovic Courtès <ludo@gnu.org> writes: [...] >>> 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’. [...] >> 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? 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. Ludo’.
Ludovic Courtès writes: Hi, > 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. Ludovic convinced me it might adverely affect the UX of the foreign system, so yeah, I also don't know. Most users that install Guix on a foreign system might be converting to Guix and look for more Guix consistancy, or they might. Let's have the universe tell us what it thinks. We tried the current situation and it's not great. Pushe to master as 78390634d76c0c75c6e93742fa7caec965194641. Greetings, Janneke
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'. "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. 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? Greetings, Janneke
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?
Maxim Cournoyer writes: Hi Maxim, > Janneke Nieuwenhuizen <janneke@gnu.org> writes: > >> Janneke Nieuwenhuizen writes: >> >> Hello, >> >>>> Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis: >>>> >>>>> Ludovic Courtès <ludo@gnu.org> writes: [..] >> 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. Ah, right. They're only available to ~/.config/guix/current/bin/guix, and thus also to its repl. >> "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? Maybe I'm confusing things. Guile will only set its GUILE_*_LOAD_PATHS if installed in the same profile; I thought the toplevel `guile' we build in guix is a hack to do just that. But I'm a bit out of my depth here. >> 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. That would be nice, I think. > 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? Good questions, who would know such things? ;) Greetings, Janneke
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. >> 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. I agree that this inconsistency isn’t great. I’m starting to use Guix on a foreign distro (NixOS) and the Guix docs gave me pointers to Geiser, but new Guix users who are also new to Guile just find themselves with a lot of cryptic errors when hacking on their Guix configuration until they figure out they need to add the Guix modules to the Guile load paths. That’s what led me to this bug. For what it’s worth, I think the latter approach is better—the default Guix System environment should be as tidy as possible. Looks like the patch was applied, but I would advocate for just documenting this better in “The Perfect Setup” and other related sections of the documentation. We can list the lines Janneke added to guix-install.sh there and users can add them to their .profile, project-level .envrc, or whatever they prefer. It’s worth noting as well that more and more distros are providing “native” Guix packages that may not use guix-install.sh at all. NixOS does, for instance. Vagrant’s Debian package looks like it tries to sync [its profile.d script] with the one from guix-install, but if so, it’s currently outdated and lacks the Guile path variables. So even if we don’t revert the patch (and don’t fix Guix System to not expose the Guix modules), updating the documentation would still be useful to users consuming foreign Guix packages. —Liam [its profile.d script] <https://salsa.debian.org/debian/guix/-/blob/b1d0628cbedea22f175a463f4c4935d02601bf93/debian/guix.sh>
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?
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
Maxim Cournoyer writes: Hi! > 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: > > # 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!
diff --git a/etc/guix-install.sh b/etc/guix-install.sh index 982fb0a266..a0bb3a556b 100755 --- a/etc/guix-install.sh +++ b/etc/guix-install.sh @@ -12,6 +12,7 @@ # Copyright © 2021, 2022, 2023 Maxim Cournoyer <maxim.cournoyer@gmail.com> # Copyright © 2022 Prafulla Giri <prafulla.giri@protonmail.com> # Copyright © 2023 Andrew Tropin <andrew@trop.in> +# Copyright © 2024 Janneke Nieuwenhuizen <janneke@gnu.org> # # This file is part of GNU Guix. # @@ -557,6 +558,10 @@ GUIX_LOCPATH="$GUIX_PROFILE/lib/locale:${GUIX_LOCPATH:+:}$GUIX_LOCPATH" export GUIX_LOCPATH +# Make Guix modules available +export GUILE_LOAD_PATH="$_GUIX_PROFILE/share/guile/site/3.0${GUILE_LOAD_PATH:+:}$GUILE_LOAD_PATH" +export GUILE_LOAD_COMPILED_PATH="$_GUIX_PROFILE/lib/guile/3.0/site-ccache${GUILE_LOAD_COMPILED_PATH:+:}$GUILE_LOAD_COMPILED_PATH" + EOF }