taylanbayi...@gmail.com (Taylan Ulrich "Bayırlı/Kammer") skribis:
> l...@gnu.org (Ludovic Courtès) writes: [...] >> (gnu scripts environment) imports (gnu packages bash), so we end up >> loading a big bunch of (gnu packages …) modules. >> >> The problem is that (gnu packages commencement) refers to (gnu packages >> bash) from its top-level. But here, we are loading (gnu packages bash) >> first, which somehow entails loading (gnu packages cross-base), which >> loads (gnu packages commencement), which sees a (gnu packages bash) >> module containing zero bindings. >> >> What’s unclear to me though is why (gnu packages cross-base) gets loaded >> in the first place. >> >> Could you investigate in that direction? > > It seems to be > > (guix scripts environment) -> (gnu system linux-container) -> > (gnu system) -> (gnu packages firmware) -> (gnu packages cross-base) Good catch. I’m not sure how to address that. We could introduce lazy references with ‘module-ref’ at any of these stages. That would work but sounds like a hack. Hmm. Ideas? :-) > It would be amazing if we could easily create graphs of Guile modules... We can do it with ‘guild use2dot’ (with the caveat that we need to explicitly load (guix gexp) before because otherwise it borks when it sees #~ and the likes.) However the resulting graph is pretty much intractable. That said, it may be nice to have a similar tool that we could also use to build Makefile rules or to make a topological sort so ‘guix pull’ builds files in topological order. But that’s more of an optimization, I think. Ludo’.