GUIX_EXTENSIONS_PATH pattern

[zimoun]

Hi Ricardo,

>> We can change this, but we’d need to agree on an as yet unused directory
>> as the root for extensions.

> We could say that:
>
>  1. the prototype of GUIX_EXTENSIONS_PATH is path/to/guix
>  2. the folder /extensions is implicitly appended 
>  3. ~/.config/guix is implicitly appended

Do we agree on this default?  Which implies…

> The patch attached does that.  But, the definition of the package ’guix’
> needs to be tweaked (not done) in agreement, especially:
>
> --8<---------------cut here---------------start------------->8---
>       (native-search-paths
>        (list (search-path-specification
>               (variable "GUIX_EXTENSIONS_PATH")
>               (files '("share/guix/extensions")))))
> --8<---------------cut here---------------end--------------->8---

…and…

>>> Moreover, it could nice to have GUIX_EXTENSIONS_PATH look by default
>>> in ~/.config/guix/extensions, i.e., by default
>>> GUIX_EXTENSIONS_PATH=~/.config.
>>
>> The last part of this sentence is what I meant above: we need to avoid
>> that, because that would cause
>> ~/.config/guix/current/share/guile/site/3.0/guix/scripts/ to be included
>> in the search for extensions.
>
> It is easy to filter out by adding rules in ’extensions-directories’. :-)

…that.

To me, the easiest is to fix the module name as ’(guix extensions foo)’
and since that is fixed, GUIX_EXTENSIONS_PATH should not declare
explicitly ’/extensions’.

I get your other points about channels.  From my understanding, the
pattern should fixed and then some other parts tweaked in agreement.

WDYT?


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?


All the best,
simon