mirror of
https://github.com/patrickchugh/terravision.git
synced 2026-05-09 08:25:25 +02:00
[GH-ISSUE #188] Replace graphviz2drawio with native mxGraph emitter #113
Labels
No labels
bug
enhancement
enhancement
good first issue
good first issue
good first issue
pipeline
pull-request
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/terravision#113
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @patrickchugh on GitHub (Apr 14, 2026).
Original GitHub issue: https://github.com/patrickchugh/terravision/issues/188
Summary
Replace the current
graphviz2drawiolibrary with a native mxGraph XML emitter that generates drawio files directly fromtfdata["graphdict"]and the existing node/cluster model inmodules/drawing.py. As part of the rewrite, wire up drawio's native provider shape libraries (AWS / Azure / GCP) instead of embedding base64 PNG icons.Motivation
Dependency pain
graphviz2drawiodepends onpygraphviz, which is a C-extension Python binding to Graphviz. This causes real pain on:CFLAGS/LDFLAGSpointing at Homebrew's Graphviz headers beforepip installsucceeds.We document a workaround in the README but it's a recurring friction point for users installing
terravision[drawio].Output quality issues
On top of the install pain, the library has several quality issues in its output that we can't easily fix without controlling the emitter:
<IMG>cluster labels we embed for the PNG path don't survive the conversion. No clean fix without a rewrite.Use native drawio shape libraries (rolled in from #182)
Today we emit every node as
shape=image;image=data:image/png,<base64>— the icon is embedded inline. This:drawio ships official libraries for AWS, Azure, and GCP. We should emit
shape=mxgraph.aws4.lambda,shape=mxgraph.azure.kubernetes_service,shape=mxgraph.gcp.compute_engine, etc. We can't do this throughgraphviz2drawiobecause it hard-codesshape=image, so the work is gated on the rewrite.Proposed approach
Emit mxGraph XML ourselves using
dot's-Txdotoutput for layout coordinates. Thedotbinary is already a required system dependency (needed for the PNG path), so we don't gain a dependency — we lose one (pygraphviz/graphviz2drawio).Pipeline
What we keep
generate_dot, cluster building,handle_group,handle_nodes)._postprocess_drawio_xmlgoes away — we produce correct XML from the start.What we write (estimate ~400–600 lines)
pos="x,y",bb="x,y,x,y",width,height,lp(label position) from each node/cluster.<mxGraphModel>/<mxCell>XML with correct hierarchy (parent=from the cluster tree), correct styles per resource type, edges with source/target mxCell IDs.Cluster/Nodesubclasses to mxGraph style strings — we already know every icon, color, and shape per resource.Benefits
graphviz2drawioandpygraphvizdependencies entirely → no more compile flags on arm64/Windows.Costs
drawing.py— worth extracting shared helpers.Scope boundaries
dotvia the PythonDiagramwrapper.terravision draw --format drawiostill works identically.Related issues
References
modules/drawing.pyrender_diagram()around theif format == "drawio":block._postprocess_drawio_xml().@patrickchugh commented on GitHub (Apr 16, 2026):
Also auto open draw.io website with generated file from terravision loaded if terravision is run with --show flag