Re: GUIX_EXTENSIONS_PATH pattern

[zimoun <zimon.toutoune@gmail.com>]

Hi Ricardo,

On Mon, 08 Feb 2021 at 23:37, Ricardo Wurmus <rekado@elephly.net> wrote:

> 1. do you mean “share/guix” here?
>
> 2. I don’t know if this is a good idea, because the extensions really
> are in the “extensions” sub-directory.  Why would the variable refer to
> a more generic parent directory?

Let take an example, the recent Ludo’s explorer.

  <https://notabug.org/civodul/guix-explorer/>

It is easy to transform it as an extension and then use “guix explore”.


But 2 things are strict:

 - user side: GUIX_EXTENSIONS_PATH
 - extensioner side: define-module

Maybe I am wrong and I miss something.  From my understanding,

 - the file must be located at $GUIX_EXTENSIONS_PATH
 - the module must be defined as (guix extension explore)

because of:

--8<---------------cut here---------------start------------->8---
    (match (search-path (extension-directories)
                        (format #f "~a.scm" command))
[...]
       (resolve-interface `(guix extensions ,command)))))
--8<---------------cut here---------------end--------------->8---


So, taking the previous example, it would be easy to say: hey, clone
this, export GUIX_EXTENSIONS_PATH as /path/to/checkout and run “guix
explore”.  But, to work, the repo must have the structure:

 - guix-explorer
   - guix
     - extensions
       - explore.scm

because the module and in the same time $GUIX_EXTENSIONS_PATH must be
“guix-explore/guix/extensions“.  I feel something is wrong.  And I
initially proposed to append ’/guix/extensions’ by default to
GUIX_EXTENSIONS_PATH in ’extension-directories’.

I do not understand why it should be a problem.


BTW, for packages as GWL, it does not change.  It is just an agreement
between the two sides, right?


> 3. My opinion is that ~/.config/guix should not get special treatment.
> People can use different profiles for “guix pull”.

Ok, fine with me.  It is reasonable to have GUIX_EXTENSIONS_PATH defined
by user preference in their ~/.bash_profile or whatever.


> Perhaps we can invite some other people to comment on this.  I have
> become confused about what is the best way forward (which is one of the
> reasons why it took me so long to reply).

For sure!  Even if we are already on guix-devel. :-)


>> BTW, I have not tried to adapt and makes it work for extension as
>> subcommand.  I have in mind: “guix git log” or “guix system foo”.  Well,
>> these subcommands are not defined as ’define-command’ but we could take
>> this road.  WDYT?
>
> I haven’t really thought about this, but extensions for sub-commands of
> sub-commands currently only work by replacing the parent command, so
> they cannot be composed.

Indeed, it is a separated topic. :-) First, the subcommand should use
something like ’define-command’.


> We probably could add a mechanism to that (guix extensions system foo)
> would extend the “guix system” command, but this would require more work
> as the “system” command is responsible for dispatching to the
> sub-command.  I don’t know if there’s a good generic way to implement
> this.  “guix system foo” could bypass the “guix system” entry point if
> (guix extensions system foo) exists, but this may have unwanted
> consequences.

Yeah, you have right.  It needs more thoughts and discussions.


Cheers,
simon