Hi all, I’m new to Guix and ran into the load path issue on foreign distros. Maxim Cournoyer writes: > Ludovic Courtès writes: > >> Janneke Nieuwenhuizen 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]