***zimoun is now known as Guest96465
***zimoun` is now known as zimoun
***zimoun is now known as zimoun`
***zimoun` is now known as zimoun
<rekado_>so, I’m still struggling with load path issues because the “guix” package uses a different “guile” than all of the other Guile packages that the GWL depends on. <rekado_>I guess I’ll have to use package transformations to rebuild these other Guile packages with the same Guile that Guix uses. <rekado_>that’s not difficult, but it is yet another quirk. <zimoun>and it’s true for any extension, right? <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_>I have an updated version of that actually <zimoun>does it make sense to have something like that directly in guix for the extensions? <rekado_>because I realized that I really only want the pristine load path from Guile and not whatever value %load-path may be at this point. <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. ***rekado_ is now known as rekado
<zimoun>I thought that the extension changed that and instead use current Guix for all. Sorry for the misunderstanding <rekado>no, I think it’s unwise to use the current Guix for everything, because we compile with an older Guix and only run the tests for that older version. <rekado>hot-swapping that old version for an arbitrary new version of Guix could be disastrous <zimoun>once you are saying that, I agree. <zimoun>I just mixed up my willing for extensions and GWL :-) <rekado>yeah, it’s possible that other extensions can do something simpler, but I don’t know. <rekado>a hypothetical AWS extension to “guix deploy” — it would need Guile-AWS, so it must augment the load path. But it should also use everything else from the current Guix. <rekado>I don’t know how this would work. <zimoun>about extensions, we should continue to discuss id:86zh19k5vv.fsf@gmail.com and conclude about the default GUIX_EXTENSION_PATH and co. <rekado>zimoun: yes, I’ll try to answer your last email in that thread tonight <rekado>next open question for the GWL is how to handle package requirements for workflows (not just processes) <rekado>say, I have a YAML config file that needs guile-libyaml, and I want to use that to figure out what arguments to pass to my process templates. <rekado>I’d need to be able to evaluate the workflow file inside an environment that contains guile-libyaml. <civodul>"user" in a broad sense (having tested it once counts) *rekado only read the blog post <rekado>but it’s what PiGx uses for settings <rekado>and it has been nothing but trouble because people keep violating the syntax <rekado>for example: having a leading space on every line causes an error. <zimoun>rekado, i would say manifest.scm at first and manifest.w at second <rekado>I want it to be part of the workflow file, though. <rekado>the difficulty of making it part of the “workflow” record (e.g. a “packages” field in that record) is that it would need to be evaluated *before* the whole file is evaluated.