Re: Extending Guix without using the Guile load path

[Ricardo Wurmus <rekado@elephly.net>]

Ludovic Courtès <ludo@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