search

sphinx-contrib / kroki

Embed PlantUML, DOT, etc. diagrams in your documentation using Kroki.
MIT License
35 stars 13 forks source link

is there a need to match diagram name against a hardcoded list, rather than forwarding the argument to the kroki server? #17

Open danieleades opened 9 months ago

danieleades commented 9 months ago

what it says on the tin.

If checking the value against a hardcoded list wasn't required, then new diagram types would not need to be manually added (and no issues with absent maintainers either...)

The 'checking' mechanism could still be used for known aliases, but fall back to a direct pass through

viktorfreiman commented 5 months ago

I am also looking in to this.

I tired to look if kroki has a api for it but I can't find any. I posted the question up to kroki https://kroki.zulipchat.com/#narrow/stream/232085-users/topic/Api.20endpoint.20to.20list.20supported.20diagrams.3F

danieleades commented 5 months ago

i'm referring to these lines - https://github.com/sphinx-contrib/kroki/blob/2665ddf784498abc14917ac7a1ab391b1a2e9bc0/sphinxcontrib/kroki/kroki.py#L19-L64

seems to me the types dict is redundant, and forces you to create a new PR to support every new diagram supported upstream. When you could instead have something like-

ALIASES = {
    "bob": "svgbob",
    "c4": "c4plantuml",
    "c4puml": "c4plantuml",
    "dot": "graphviz",
    "dsl": "structurizr",
    "er": "erd",
    "gv": "graphviz",
    "iuml": "plantuml",
    "pu": "plantuml",
    "puml": "plantuml",
    "uxf": "umlet",
    "vg": "vega",
    "vgl": "vegalite",
    "vl": "vegalite",
    "wsd": "plantuml",
}

def diagram_name(name: str) -> str:
    return ALIASES.get(name, name)
viktorfreiman commented 5 months ago

Yea I agree. I got back from kroki that we can use https://kroki.io/health to get a list of available diagrams. I will see if I can get a PR together