IRC channel logs


back to list of logs

<rekado>new GUIX_EXTENSIONS_PATH proposal:
<rekado>I tested this with an unreleased change to the GWL
<rekado>the GWL entry point is still a Guile module and it must use define-command, so that “guix --help” can list it
<rekado>that module sets up the %load-path and %load-compiled-path before launching the actual command
<zimoun>rekado: cool for GUIX_EXTENSIONS_PATH! :-) What is the point of guile-config?
<rekado>declarative specification of options and configuration files
<rekado>It’s just so much nicer than having to manually format (and keep up-to-date) help/usage texts, manually validate arguments, etc
<rekado>here’s how part of this looked like before:
<rekado>above is the show-help procedure with a manually formatted string
<rekado>there was also this:
<rekado>all of this is now unified, specified declaratively
<zimoun>yeah, this looks really better :-)
<rekado>thought about GUIX_EXTENSIONS_PATH: I think I’ll have to use something other than guix/scripts/ as the directory.
<rekado>say you have “guix” itself installed in a profile; all the Guix scripts themselves would end up being considered extensions, which is obviously incorrect.
<rekado>you aren’t supposed to install “guix” into your profile, but it’s probably better to be safe
<zimoun>rekado: I have not look into the details of your recent patch, but what I would like to have is “guix foo” where ’foo’ is a Guile module living somewhere, say GUIX_EXTENSIONS_PATH. That way, it would fully replace “guix repl -- path/to/module/foo.scm”; which is somehow another way to extend. :-)
<rekado>zimoun: yes, that’s working
<rekado>the extension must be defined with (define-command …), so it depends on (guix scripts); other than that it can do anything.
<rekado>the GWL case is trickier
<rekado>I remember that we discussed this before…
<rekado>for the GWL it’s important that the very same Guix is used that the user invoked.
<rekado>under normal circumstances this would always be the case
<rekado>but the GWL has to override/augment the Guile load path
<rekado>to avoid conflicts it’s safer to override everything, including the Guix modules.
<rekado>but then later when we compute derivations and all that … we need that initial Guix again
<rekado>so I’m thinking that the GWL entry point should record the initial Guix and then use “guix repl” down the line
<rekado>…instead of using the Guix modules for computing profiles directly
<civodul>hey rekado!
<civodul>we need a good story for tools that extend Guix
<civodul>so that they can use the current Guix instead of the one passed at build time
<rekado>do you think the “guix repl” trick might work?
<civodul>i'm not sure what you meant
<rekado>so … there are two independent “levels” of Guix that the GWL uses
<rekado>the first is the library that provides (guix scripts), for example, and other “stable” features
<rekado>the second is the build machinery which has access to the channels
<rekado>only the second really needs to be the current guix
<civodul>but, couldn't the whole process re-exec itself with "guix repl" instead of "guile"?
<rekado>initially I thought I may have to do all these computations inside of an inferior
<rekado>the “whole process”… I don’t know. The whole process uses Guix as a library and we cannot guarantee that the extension will work with later versions of Guix.
<civodul>or you could use an inferior just to learn the load path of "guix repl"
<civodul>and extend your load path with that
<rekado>we have the load path at the entry point
<rekado>the latest version of the patch uses LOAD on the extension and executes the procedure corresponding to the command
<rekado>at that point we still have the original load path
<civodul>which patch?
<civodul>i guess i'm lagging behind
<rekado>this one:
<rekado>it only needs a slight modification to use guix/extensions instead of guix/scripts; but the idea is the same
<rekado>a few months ago I tried to implement the inferior route, but using the invoking Guix instead of creating a new inferior from channel specs; it did not go well, because the API doesn’t allow me to just invoke any Guix (such as ~/.config/guix/current/bin/guix) as the inferior.
<rekado>I suppose it would work with “guix repl”, though
<rekado>I’d make the GWL spawn a “guix repl” process and evaluate all the environment/profile computations in there.
<civodul>doesn't using an inferior prevent you from doing interesting things?
<rekado>maybe. I don’t know.
<civodul>the GUIX_EXTENSIONS_PATH looks reasonable to me
<civodul>shouldn't $GUIX_EXTENSIONS_PATH be appended to %load-path?
<rekado>I did not do that because I didn’t want the extension to have too much power over Guix
<rekado>setting GUIX_EXTENSIONS_PATH should only have a small effect on Guix: 1) it should list the extension in the help output, and 2) it should be able to execute it.
<rekado>I don’t want this to be a mechanism through which people can arbitrarily override Guix modules.
<civodul>but for #2, its modules must be on %load-path, right?
<rekado>I use (load "/the/one/file/that/was/requested.scm“)
<rekado>that makes the module (and only that one module) available.
<civodul>but then if that one wants to load (gwl specific module), it needs to adjust %load-path, right?
<civodul>but yeah, we don't have to do it upfront
<rekado>this is the GWL entry point:
<civodul>i see, makes sense
<civodul>i guess part of the weirdness is that the extensions builds against a different Guix than the one it sees at run time
<civodul>channels ensure consistency, but they're also very limiting
<civodul>i remember we ruled them out earlier
<rekado>we did.
<rekado>again because of load-path problems: I cannot declare arbitrary packages as dependencies of my channel
<civodul>i'm trying to see a pattern but it doesn't click
<civodul>maybe channels should more closely resemble packages somehow
<civodul>.guix-channel could also declare dependencies on packages of the host guix
<civodul>but anyway, GUIX_EXTENSIONS_PATH should work fine
*civodul backtracks
<rekado>another problems with channels is that they are not built ahead of time like packages
<civodul>hmm i can't wrap my head around it, it's terrible
<rekado>I’m not really happy with extensions the way they happened to fall into place, because they don’t *actually* extend Guix.
<rekado>hooking into ‘guix pull’ really does seem to be the right thing to do, because then we only ever need to deal with one Guix
<rekado>however, development of extensions will be terrible
<rekado>because you’ve got this moving target
<civodul>GWL both extends and uses Guix
<rekado>maybe in practise it’s not *that* bad, but I don’t like to be in a situation where things could suddenly break and I need to fix things ASAP to restore the GWL.
<civodul>for hpcguix-web and Guix-Jupyter, an inferior was good enough
<civodul>but i don't know if that generalizes to more involved tools like GWL
<rekado>I guess I’ll just need to implement it to see how far I can go.
<rekado>one limitation of the inferior API was that I need to give it channels; I can’t just open an inferior to the *current* Guix.
<civodul>that should be doable
<civodul>i think i did that somewhere
<civodul>if you do (open-inferior "/home/rekado/.config/guix/current"), tshou'd work
<rekado>oh, that’s great
<rekado>(has this always worked and I just didn’t realize it…?)
<rekado>thanks! I’ll start playing.
<civodul>good :-)