Add --template-dir CLI option (port of upstream PR #444)#3
Conversation
Lets users point WireViz at an explicit directory of HTML templates
when resolving a metadata.template.name reference. Useful for shared
branded chrome that lives outside both the YAML source tree and the
output tree.
CLI:
wireviz -t ./brand-templates harness.yml
Programmatic:
wireviz.parse(yaml_str, output_formats=("html",),
template_dir="./brand-templates", ...)
The new explicit path is searched first, before the implicit ones
already in place. Final lookup order:
1. --template-dir / parse template_dir (explicit)
2. YAML source directory (source_path.parent) (PR wireviz#473)
3. output directory (existing)
4. WireViz built-in templates (fallback)
Adapted from wireviz#444 (originally by
@tbornon-sts) — the upstream patch used inconsistent naming
(``templatedir`` on the kwarg, ``template_dir`` on the CLI option) and
included a leftover ``print("Test")`` debug statement; this port uses
``template_dir`` consistently and drops the debug line.
Verified against build_examples.py (deterministic outputs unchanged)
and against a manual case with a custom branded.html living only in
the -t directory: template resolves correctly, and absence of -t
produces a clean "was not found" error from smart_file_resolve.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Code Review
This pull request introduces a new template_dir parameter across the library and CLI to allow users to specify a custom directory for HTML templates. The changes include adding the parameter to the Harness.output, Harness._render, and parse functions, as well as implementing a new -t/--template-dir option in the CLI. The template resolution logic in generate_html_output was also updated to prioritize this new directory. Feedback was provided to ensure that the new parameter is properly documented in the docstrings of the modified functions and methods.
| cleanup: bool = True, | ||
| output_dir: Optional[Union[str, Path]] = None, | ||
| output_name: Optional[str] = None, | ||
| template_dir: Optional[Union[str, Path]] = None, |
| fmt: Union[str, Tuple[str, ...], List[str]], | ||
| output_dir: Optional[Union[str, Path]] = None, | ||
| output_name: Optional[str] = None, | ||
| template_dir: Optional[Union[str, Path]] = None, |
| output_name: Union[None, str] = None, | ||
| image_paths: Union[Path, str, List] = [], | ||
| source_path: Union[Path, str, None] = None, | ||
| template_dir: Union[Path, str, None] = None, |
|
@tbornon-sts — heads up, your upstream #444 ( Context: We use WireViz to document Classic Mini Cooper wiring harnesses at Classic Mini DIY and are building a GUI on top of it. Upstream
Search order ended up as: explicit Commit attribution links back to your PR. Thanks for the work. |
Addresses gemini-code-assist feedback on #3 — template_dir was missing from the docstrings of Harness.output(), Harness._render(), and wireviz.parse(). Expanded scope to also document the parameters that earlier PRs in this chain added without docstring coverage: * Harness.output(): Args section now describes filename (incl. None → stdout semantics), fmt (incl. str→tuple normalization), output_dir, output_name, and template_dir; view/cleanup are noted as kept for API compat. * Harness._render(): Args + Returns sections describing fmt, output_dir, output_name, template_dir, and the bytes-vs-str per-format return contract. * wireviz.parse(): source_path (added during PR #1's loopback fix and threaded through PR #2's stdin/stdout port) and template_dir (this PR) added to the Args section, with template-search-priority semantics spelled out. No behavior change. Verified against build_examples.py: deterministic outputs unchanged. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
Ports upstream PR #444 — adds a
-t/--template-dirCLI option (and correspondingtemplate_dirparameter onwireviz.parse()) that lets users point WireViz at an explicit directory of custom HTML templates.Useful for shared branded chrome that lives outside both the YAML source tree and the output tree — e.g. an org-wide
harness-templates/repo checked out separately.Usage
Template resolution order
The explicit
template_diris searched first, ahead of the implicit paths already wired up by previous PRs:--template-dir/parse template_dir(explicit, this PR)source_path.parent) — from Fix template search path wireviz/WireViz#473Differences from upstream PR wireviz#444
templatediron the kwarg vstemplate_diron the CLI option. This port usestemplate_direverywhere.print(\"Test\")debug statement that was in the upstream diff._render→generate_html_outputchain (which has evolved past upstream master since resolves #320 read from stdin and write to stdout wireviz/WireViz#321 / Fix template search path wireviz/WireViz#473).Verification
build_examples.pyruns clean across all 14 examples + 8 tutorials + 2 demos; deterministic outputs (.gv,.bom.tsv) byte-identical to baseline.branded.htmltemplate living only in a-tdirectory (not next to the YAML, not in the output dir) resolves correctly and renders. Absence of-tproduces a clean\"branded.html was not found in any of the following locations\"error fromsmart_file_resolve.Test plan
wireviz -t /some/dir harness.ymlrenders with custom templatetemplate_dirvstemplatedir)🤖 Generated with Claude Code