torchvista draws the forward pass, and its install list quietly leaves out PyTorch

The install list has IPython and NumPy, and no PyTorch

The usage section is one line long: `trace_model(model, inputs)`, with the full signature shown separately as a keyword list. What is easy to miss is what the package asks for. setup.py declares two install requirements, `ipython>=7.0.0` and `numpy>=1.18.0`, and neither of them is PyTorch. A second file at the root disagrees with the first: requirements.txt lists `torch>=2.0.0` alongside `ipython>=7.0.0`, and drops numpy entirely. So the two dependency sources are not subsets of each other, and neither of them is a complete picture. The practical effect is that installing the package into a clean environment leaves you with a package whose entire purpose is tracing a model you cannot import, while the documentation's own example begins by importing torch.

pip install torchvista

Two distribution routes exist, pip and conda, and the conda route points at a separate feedstock repository for the channel.

Eleven parameters, three categories, and one default that hides your model's internals

The signature sorts itself into three groups, which is the fastest way to read it. Tracing holds the model, the inputs, and `forced_module_tracing_depth`, which defaults to `None` and in that state traces only user defined modules, so library internals stay out of the graph until you name a depth. Visual holds the rest: `collapse_modules_after_depth` defaults to 1, and 0 collapses everything while still letting you expand any node by hand, `height` is 800 pixels, `width` accepts pixels or a percentage string and falls back to the full available width, and `show_module_attr_names`, off by default, swaps class names for attribute names where they exist. Export holds `export_format` and `export_path`, both `None` by default, which is what leaves the graph drawn inside the notebook rather than written to disk. The compression switch sits in the visual group and carries an experimental label in its own name.

Three export formats, and only one of them honours a custom path

`export_format` accepts png, svg, or html, and its row is explicit that without it the graph is simply shown inside the notebook. The `export_path` row is where the constraint lives, and it is bolded in the table. Only the HTML format is currently supported with custom export paths. The second half of that row describes the fallback: if you supply just a file name, it is created inside the present working directory. So for png and svg the path argument has no effect, and the destination is whatever the viewer would otherwise do with a download. That makes html the format to reach for when a figure has to land at a specific path for a report, and it is worth knowing before you build a script that assumes the other two will honour a path. The export assets themselves ship as package data, with the table patterns naming an html template directory and an assets directory.

The compressed view is experimental, recognises two container types, and warns about cost

`show_compressed_view` is the one parameter marked experimental in the table, and its description carries the only explicit warning anywhere in the API: the feature might be expensive on large models. What it does is merge repeating nodes of the same type that share identical input and output dimensions into a single repeat block, which is the difference between a readable transformer diagram and a wall. The limit is stated in the same row: repeating nodes are only recognised within `Sequential` and `ModuleList`. A model built from its own block class, or from any other container, gets no compression from this switch regardless of how repetitive it is. It also defaults to `False`, so the behaviour people see first is the uncompressed graph, and anyone evaluating the tool on a large model is switching on the expensive path deliberately.

Error tolerance is the feature the page leads with, and it is aimed at shape mismatches

Of the four feature headings on the page, the one that matters most for debugging is error tolerance: when something goes wrong, such as a shape mismatch, the tool draws the part of the forward pass that worked instead of returning nothing. That is a different contract from a graph library that either renders or raises, and it is why the package is worth a look even if you only use it when something is already broken. The other three are the expected ones, drag and zoom, collapsible nodes for hierarchical modules, and click a node to read its parameters and attributes. None of the four is accompanied by a screenshot on the page, so the evidence for all of them sits on the documentation site instead, which carries a step by step tutorial and a demos page. The Colab tutorial is a third option and it asks you to be logged in to Colab first.

The internals question is answered on a blog post, not in the repository

There is a heading that asks how the tool works, and the answer is a link to a technical deep dive published on Towards Data Science. Nothing in the repository itself explains the tracing mechanism, the graph construction, or the front end, even though a docs directory sits at the root and the project hosts its own documentation site. So the architecture lives outside the version control, in a post written for a general audience, and a reader who wants to know how a node gets its dimensions or why error tolerance works the way it does has to leave the project to find out. A scripts directory sits at the root as well, and the page says nothing about what is in it or how to run it. The one development command that is documented belongs to the tests, not to the internals: tests live under tests and run with pytest after an editable install of the test extra.

pip install -e ".[test]"
pytest

The version says 0.2.13, the classifier still says Alpha, and the PyPI blurb is plain text

setup.py declares version 0.2.13, which matches the newest tag, published on 2026-09-05. The two before it are v0.2.12 in May and v0.2.11 in February, so the release rhythm is a handful of patches spread over months rather than a stream. Against that, the classifier block still reads Development Status 3 - Alpha, with no beta marker anywhere in the metadata. Two smaller packaging notes are visible in the same file. The long description is marked as plain text content, so the package page renders it without formatting even though the project page itself is markdown. And `include_package_data` is on with patterns for an html template directory and an assets directory, but no manifest file appears at the root, which leaves what ships inside the wheel to whatever the build backend collects from the tree. The licence is GPL-3.0 with a NOTICE file beside it.

Editorial conclusion

torchvista earns a place in a notebook that already has PyTorch, a GPU, and an environment where an interactive graph beats reading a stack trace, and the partial-graph behaviour is the reason to try it. Two things to check first: whether your model uses containers other than Sequential and ModuleList, since the compressed view only recognises those, and whether you need a custom export path for anything other than HTML, because the other two formats ignore it.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. sachinhosmani/torchvista on GitHub