Hi Ricardo, On Mon, 08 Feb 2021 at 23:37, Ricardo Wurmus <[email protected]> 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
