<rekado_>any extension that uses other Guile packages
<rekado_>I’m writing a package-mapping procedure now; would have been nice to use package-input-rewriting/spec, but it doesn’t let me cut the recursion early.
<rekado_>I don’t want it to replace *all* Guile variants throughout the graph. I don’t care about the Guile used in “make”, for example.
<zimoun>if you set #:deep #f, the cut is not enough?
<zimoun>speaking at the extension level, assume that I want to extend, i.e., “guix foo” where ’foo’ depends on some guile-<package>s. Where do I have to specificy these guile-<package>s? In order to be findable by (use-modules ())?
<rekado_>it might actually be enough to set #:deep? to #false
<rekado_>it still traverses a lot of packages this way, but I guess it’s fine
<zimoun>yeah rewrite the graph is costly. :-) If you know ahead of time the depth of the graph, you could cut early… but that’s “error-prone”, IMHO.
<rekado_>I know that I want to cut as soon as the package name isn’t “guile-*”
<rekado_>because I know that all inputs that are built with the wrong Guile are packages with that name prefix.
<zimoun>Rewrite for only the explicit inputs of GWL, right? And since there is no Guile build-system, the Guile compiler is specificed as inputs for all the “guile-“, right? Therefore, the rewrite could be done by hand instead of traverse all the graph with package-input-rewriting/spec even with #:deep #f
<zimoun>(I am not convinced by the #false switch :-))
<rekado_>it still needs to be done recursively, because the Guile inputs of GWL may also have Guile packages as inputs.
<zimoun>so it is hard to know the depth of the graph ahead of time.
<rekado_>yes, but with an extra predicate I could cut as soon as a package name doesn’t start with ‘guile-’
<rekado_>re your extension question: the other Guile packages must be on the load path (and load-compiled-path)
<rekado_>for the GWL I capture the values of GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH and explicitly set %load-path and %load-compiled-path in the extension entry point.
<rekado_>(it’s a little more complicated than that in reality, but this is the gist of it)
<zimoun>about extension, you mean the dance in ’replace-load-paths’ from guix/exensions/workflow.scm.in right?
<rekado_>because the actual values of @GUILE_LOAD_PATH@ and @GUILE_LOAD_COMPILED_PATH@ are only available at build time — when the extension is built.
<rekado_>i.e. the load path containing all of the extension’s Guile packages.
<rekado_>interestingly, guile-commonmark fails its check phase with guile 3.0.5, but passes its tests with 3.0.2.
<zimoun>I have to think a bit about this build-time and run-time paths. Somehow, from the Guix side and with an user perspective, I could be nice to have something where you write your extensions, specifying the package dependencies “somewhere” (say $GUIX_EXTENSION_PATH/<xyz>.scm), then “guix foo” does all the job.
<rekado_>for the GWL I found it best to pretend that Guix is a library that does *not* contain any package definitions.
<rekado_>*any* package lookup must happen through an inferior.
<rekado_>but all the other features like setting up a container, copying things around, talking to inferiors, defining packages etc — all that is done via Guix as a library.
<rekado_>I guess it would be easier to extend Guix if it were split into a semi-stable library and a package collection using that library, but that’s hard to maintain and even harder to accomplish.
<zimoun>Guix as a library, but the library from current Guix and library from the package guix. From my understanding, current Guix. Right?
<rekado_>ignoring package definitions allows me to use the build-time load path, which includes (the older variant of) Guix itself.
<rekado_>the library comes from the “guix” package, but packages come from the current Guix.