IRC channel logs

<PurpleSym>It looks like Guile creates an empty, globally available module when the load procedure fails to eval the body of a module. Can I prevent that somehow?

<civodul>PurpleSym: the define-module form leads to the creation of a module

<civodul>if what comes next causes an exception, then you may not have all the bindings available in that module

<PurpleSym>My problem is that the importer sometimes creates invalid packages (missing dependencies, broken descriptions, …) and I have to filter those out.

<PurpleSym>Yeah, that’s exactly what I’m seeing, civodul.

<PurpleSym>And there does not seem to be a way to load a module without affecting the global module namespace.

<civodul>so the importer create syntactically invalid modules?

<civodul>i mean, things that throw an exception when you load them?

<PurpleSym>Yes, for some CRAN modules. Sometimes the Texinfo markup is broken, sometimes a dependency does not exist and a variable is not resolved.

<PurpleSym>(Technically I’m creating one module per imported package.)

<civodul>can we fix the broken-Texinfo problem?

<civodul>unbound variables should not be an issue, because those references are in thunked fields like 'inputs'

<civodul>so that won't prevent Guile from loading the module

<civodul>broken Texinfo can be an issue if you enable compile-time Texinfo validation (that's the case when using ./pre-inst-env)

<rekado_>PurpleSym: when you generate countless CRAN packages for a channel do you really care about descriptions and the like?

<rekado_>or is this for something else?

<rekado_>the importer doesn’t create texinfo markup by itself, or does it?

<PurpleSym>No, the importer does not create texinfo, but some description contain unescaped @ symbols, which are interpreted as markup.

<PurpleSym>civodul: You’re right, it’s not the variables itself, but me importing the corresponding module (i.e. r-foobar from (guix-cran packages r-foobar)).

<PurpleSym>I guess I’ll have to shell out to avoid the namespace pollution.

<rekado_>PurpleSym: ah, I see. We should update beautify-description then to escape @.

<rekado_>PurpleSym: have you compared your variable references with specification->package?

<rekado_>(in terms of performance)

<PurpleSym>rekado_: No, I haven’t benchmarked that yet.

<rekado_>if you have a package that exhibits an unescaped @ please tell me and I’ll add a test case and fix it in beautify-description.

<PurpleSym>rekado_: r-analysispipelines, r-bwgs, r-dief, r-psychmeta, r-recometrics, r-survtrunc, r-syllabifyr, r-tgs, r-tribe, r-trophicposition

<PurpleSym>All of them fail due to texinfo markup issues.

<rekado_>thanks

<rekado_>I’m rewriting beautify-description right now and extend it with a few more features.

<PurpleSym>Thanks 🙂

IRC channel logs

2022-10-05.log