[sideshowb]

Very pretty!

Out of interest, I'm thinking how this sort of method works if you ignore the semi-arbitrary distinction between your own code and other libraries. If, say, an array class is used everywhere, wouldn't that look like a bad pattern on the dependency graph? Or is there a way to read the graph that tells you that your pervasive use of np.array is still appropriately decoupled?

[gabimtme]

That's taken into account while rendering the graph. The attraction force between two nodes is inversely proportional to the number of edges a node has.

If a node is depended upon a lot, all the resulting edges induce weaker forces to adjacent nodes, so this accounts for the fact that some files will be depended upon a lot, and that's fine.

There's also the option to just exclude that kind of files from the analysis with the --exclude flag. I've found that to be useful for massive auto-generated files.

[olejorgenb]

While excluding nodes which a huge portion of the code depends on is one solution to make the graph less messy, I think an interesting alternative would be to allow certain nodes to be duplicated. If the "energy" of the system could be reduced above some threshold by duplicating a node, duplicate it and connect the edges to minimize the "energy". Alternative let me configure that these nodes can be copied N times.