Hi,
sorry for the delay! zimoun <[email protected]> writes: >>> 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… I’m really not sure. 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? 3. My opinion is that ~/.config/guix should not get special treatment. People can use different profiles for “guix pull”. >> 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’. 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). > 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. 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. -- Ricardo
