Add support for Wire diagrams

Input

connectors:
  X1:
    type: D-Sub
    subtype: female
    pinout: [DCD, RX, TX, DTR, GND, DSR, RTS, CTS, RI]
  X2:
    type: Molex KK 254
    subtype: female
    pinout: [GND, RX, TX]

cables:
  W1:
    gauge: 0.25 mm2
    length: 0.2
    color_code: DIN
    wirecount: 3
    shield: true

connections:
  -
    - X1: [5,2,1]
    - W1: [1,2,3]
    - X2: [1,3,2]
  -
    - X1: 5
    - W1: s

Output

Format:

• mywire.gv GraphViz output
• mywire.svg Wiring diagram as vector image
• mywire.png Wiring diagram as raster image
• mywire.bom.tsv BOM (bill of materials) as tab-separated text file
• mywire.html HTML page with wiring diagram and BOM embedded

We can start by supporting png and svg.

Runtime

Python 3.7

Project

https://github.com/formatc1702/WireViz

[jhogendorn]

https://github.com/jhogendorn/kroki-wireviz

I’ve thrown together a quick POC. if you pull it and run make build you can then make run and then make demo-svg

• Runs on port 8010.
• uses .tool-versions from asdf.
• Locks versions (dockerfile uses .tool-versions)
• theres a basic test suite, make test,
• groundwork scope for container based testing
• poetry based
• pytest based functional tests

it supports png/svg as thats what wireviz outputs natively. we could grab a diff lib to convert from svg to arbitrary image formats.

I spent a short while setting up a ‘more correct’ production dockerfile but lost interest in fiddling with it at this POC stage.

PR’s welcome.

[jhogendorn]

That’s quite nice, I didn’t know this tool but I will closely evaluate it because the packaging and dependency management in Python is definitely convoluted and hard to understand!

Python package management is really poor in general, and python people seem to be really blind to it. Poetry is… fine, its better than pip and other solutions. its kind of like npm a bunch of years ago.

Integration-wise, I’m considering using one companion container per technology stack rather than one companion container per diagram library. Both solutions have advantages and disadvantages but I feel like we could be more resource-efficient.

I would prioritise for maintainer sanity rather than resource efficiency. combining containers may save you some incredibly minor, unnoticeable amount of resource, but make maintainer complexity much harder. version management, diff tools needing diff versions of python or libraries or whatever. I personally would keep it one thing one container.