Maxim Cournoyer writes: > Liam Hupfer writes: > >> Maxim Cournoyer 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