IRC channel logs


back to list of logs

***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>ah yes
<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/ 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_>not sure if that’s feasible, though
<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_>(via inferior)
<zimoun>ah I see
***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 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>GWL's gonna be super hype
<civodul>(any plans for a Go rewrite?)
<civodul>any Guix-Jupyter user here?
<civodul>"user" in a broad sense (having tested it once counts)
*rekado only read the blog post
<rekado>YAML is so horrible!
<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.
<civodul>arf, YAML kinda rhymes with trouble