kroki icon indicating copy to clipboard operation
kroki copied to clipboard

Add support for Wire diagrams

Open ggrossetie opened this issue 4 years ago • 6 comments

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

demo01

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

ggrossetie avatar Jun 25 '20 06:06 ggrossetie

I'd quite like to see this, is there documentation on how to create a companion container that the gateway can consume?

jhogendorn avatar Aug 18 '22 17:08 jhogendorn

The "protocol" between the gateway and companion containers is not yet formalized but currently we are using HTTP.

Request

The gateway will issue a POST request with the content of the diagram in the body (as plain-text encoded in utf8). The output format is part of the URL path: /png, /svg...

Response

Body

Body contains the image

Header

You should set the Content-Type: image/png, image/svg+xml...

Status code

  • 400 if there's a syntax error or if the output format is unsupported
  • 500 if there's an internal error
  • 200 if everything went well

ggrossetie avatar Aug 18 '22 18:08 ggrossetie

Currently, the registration is not dynamic but I guess we could implement a discovery mechanism 😉 Let me know if you have any questions.

ggrossetie avatar Aug 18 '22 18:08 ggrossetie

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 avatar Aug 22 '22 13:08 jhogendorn

poetry based

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!

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

Nice work 🎉

PR's welcome.

I will take a closer look in the next days/weeks.

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.

ggrossetie avatar Aug 24 '22 21:08 ggrossetie

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.

jhogendorn avatar Aug 25 '22 03:08 jhogendorn

Any new here? @ggrossetie have you decided when ever to you one companion per library or per technology stack? I'm still very interested to see wireviz in kroki.

copyrights avatar Jan 29 '23 17:01 copyrights

btw, thanks @jhogendorn. works like charm grafik

copyrights avatar Jan 29 '23 20:01 copyrights

Hi! It doesn't look like the kroki-wireviz docker image has been pushed to docker hub?

kartben avatar Feb 28 '23 18:02 kartben

Not yet, it will be part of the next release.

ggrossetie avatar Mar 01 '23 17:03 ggrossetie