IRC channel logs
back to list of 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_>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? <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_>I’m rewriting beautify-description right now and extend it with a few more features.