I would like to be able to obtain a graph data structure representing the modules that were part of a Nixpkgs module system configuration evaluation.
I couldn’t find a way to achieve this. Did I miss something? Otherwise, would this be a desirable addition?
This isn’t part of the module system interface yet. I suppose it could be?
collectModules is a private function which is responsible for finding all the modules, so it could be changed to return them not as a list of a module but something richer that can be preserved and returned by evalModules.
Note that the first thing it does (or “last” in terms of data) is map (attrs: attrs.module). Moving that responsibility to evalModules would make it possible to access some of those internals.
I’d want to make sure that memory usage doesn’t regress, but the implementation of lexical closures in the evaluator is rather naive, so I wouldn’t be surprised if it doesn’t make a difference anyway. Probably more important is that we don’t expose more internals publicly on a wholesale basis because that will make it harder to evolve the system. That should be a matter of doing a bit of map/mapAttrs (v: { inherit foo v; }) in this new evalModules output attribute.