Ludovic Courtès <l...@gnu.org> writes:
> What if an extension could instead be a package installed next to Guix > and its channels in ~/.config/guix/current, and we use > ‘package-path-entries’ as is done in (gnu packages) to augment > ‘%load-path’ and ‘%load-compiled-path’? I’m not sure if that would complicate installation too much. Installing a package in the “guix pull” profile suggests to me that it is installed when “guix pull” is run, and not by “guix package -p ~/.config/guix/current -i my-extension”. I suppose it would help with propagated inputs, because they would also end up in the “guix pull” profile, but perhaps that’s not really desirable as an extension probably should not be able to accidentally break Guix just because it uses a different version of a Guile library that Guix also happens to use. Keeping the directory tree of the extension separate from the “guix pull” profile would ensure that the core features of Guix keep working, no matter how badly broken an extension might be. So I’m thinking that we should instead define GUIX_EXTENSIONS_PATH as a list of directories containing merely the *entry points* for additional Guix commands. For example, the GWL would provide a script “workflow” in a directory $prefix/share/guix/extensions/ (or whatever), and that script is a wrapped executable that sets its own %load-path and %load-compiled-path as needed (and determined at build time). All Guix does is search for matching executables on GUIX_EXTENSIONS_PATH when asked for an unknown command. This is disappointingly simple, but I think it’s one of the safest things to do. An incidental side effect of doing things this way is that extensions could, in theory, be written in languages other than Guile (stretching the meaning of “extension” to its limits). -- Ricardo
