Support anonymous functions and unknown files

[giomf]

A: Anonymous function are used in the option definition:
modules/aspects/definition.nix, via option den.aspects.zagreus.includes.\"[definition 2-entry 1]\".<function body>.<function body>.includes.\"[definition 1-entry 8]\".<function body>.nixos.
At least we get the source and module path to create a meaningful node.

B: Unknown file are used in path definition:
<unknown-file>, via option den.aspects.zagreus.__functor.<function body>.<function body>.__functor.<function body>.<function body>.includes.\"[definition 1-entry 3]\".<function body>.includes.\"[definition 1-entry 8]\".<function body>.nixos.
In this case we have no source neither a module path which makes it impossible to create a node and use it in our graph. Using <unknown-file> as source and path will result in one node with many edges that are incorrect. Maybe we can use the key attribute to distinguish between these unknown nodes?

This could be because of Unify

[vic]

Unify is not the problem. The Nix module system is using those locations because of lambdas and list entries. What I wanted to say in #1, is that I first observed this issue in Unify, not that unify is the problem, when I was trying to resolve modules at vic/dendrix project.

I just want to understand, why you say it is a problem ? The graph should be able to be constructed from any module system (taking Unify and Den out of the matter).

You'd see the same kind of locations even without Unify/Den, the best approach is for people to explicitly set _file on each module, but I guess most people just wont do that.

I will explore setting _file in flake-aspects which is used by Den to generate resolved config modules. That will help a lot removing those <function body> and [entry 1..].

But my guess is that your tool needs a generic solution here, not particularly limited to Den, because again, those <function body> locations are provided by the Nix module system by default.

[giomf]

Hey vic!

Thank you again for clarifying the context. Now I understand.

But my guess is that your tool needs a generic solution here, not particularly limited to Den, because again, those locations are provided by the Nix module system by default.

That makes perfect sense.

[giomf]

Regarding A:
For now my approach is to replace the chain of anonymous function calls with a placeholder <unknown-function-chain>. This streamlines a node somewhat, and since the anonymous functions do not add any value anyway, I don't think we are losing any relevant information.

Regarding B:
I have successfully managed to get unknown modules into the graph with the help of the key attribute. Currently, this makes the graph very large and confusing.

My idea to prevent this would be to remove all nodes that do not add any further information to the graph by grouping chains of unknown modules into one. An additional information of how many nodes were grouped will be applied. Also, when the option attribute is present in an unknown module, it should only be grouped by this option with other unknown modules with the same option.

1. Unknown modules that are imported by a known module

---
title: From
---
graph LR
    A[Known] --> B[Unknown] --> C[ Unknown] 

Loading

---
title: To
---
graph LR
    A[Known] --> B[2 Unknown] 

Loading

2. Nodes that exist between known modules:

---
title: From
---
graph LR
    A[Known] --> B[Unknown] --> C[Unknown] --> D[Known]

Loading

---
title: To
---
graph LR
    A[Known] --> B[2 Unknown] --> D[Known]

Loading

[vic]

how about removing unknown entirely, how does the graph looks, does it make sense ? Can you share an image of it ? My browser (chrome) just renders nothing when clicking on your large svg.

[giomf]

just renders nothing when clicking on your large svg

It should render something but its zoomed in. Can you use the scrollbars to navigate?

how about removing unknown entirely

Yes its make sense but it would mean to loose some information about the potential option one unknown module has.