The Fractal Geometry of Software: What PyTorch and Ray Reveal

Code search can find a function, and retrieval-augmented generation can retrieve relevant passages, but neither approach explains how software modules depend on one another. A codebase functions as more than a collection of text; it is a directed structure where files import modules, modules connect to other modules, and certain paths lead back to their origin.

We extracted public Python import graphs for ten repositories and published the sanitized JSON in the Platino Labs Data Room. These graphs expose structural facts that passage searches cannot answer: the shape and scale of strongly connected components within the declared import graph. Retrieval systems and dependency graphs solve distinct problems, as similarity between passages does not indicate whether module A imports module B or how many modules participate in a cycle.

The processing pipeline parses Python source code using the abstract syntax tree (AST) to extract import relationships and publish a graph rather than relying on language model embeddings. For a fixed source revision, the extraction transforms syntax into deterministic edges. The release introduces a strongly connected component (SCC) layer, utilizing iterative Tarjan followed by Kahn's topological ordering.

Stock photo for illustration only, not from the actual event

The largest PyTorch component contains about 65.7% of the modules in its graph, whereas Ray's largest contains about 23.4% of its 4,108 modules. These numbers measure topology rather than engineering quality, detailing how many components exist, how many are cyclic, and the scale of the largest cycle. Import cycles can influence startup and initialization when dealing with eager imports, making isolated testing and refactoring more complex.