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
