IRC channel logs
2021-01-05.log
back to list of logs
<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>above is the show-help procedure with a manually formatted string <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>the extension must be defined with (define-command …), so it depends on (guix scripts); other than that it can do anything. <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>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? <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" <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 <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? <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 <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>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 <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 <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>if you do (open-inferior "/home/rekado/.config/guix/current"), tshou'd work <rekado>(has this always worked and I just didn’t realize it…?)