Skip to content

Add --template-dir CLI option (port of upstream PR #444)#3

Merged
SomethingNew71 merged 2 commits into
port-321-stdin-stdoutfrom
port-444-template-dir
May 5, 2026
Merged

Add --template-dir CLI option (port of upstream PR #444)#3
SomethingNew71 merged 2 commits into
port-321-stdin-stdoutfrom
port-444-template-dir

Conversation

@SomethingNew71
Copy link
Copy Markdown

Summary

Ports upstream PR #444 — adds a -t / --template-dir CLI option (and corresponding template_dir parameter on wireviz.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

wireviz -t ./brand-templates harness.yml
wireviz.parse(yaml_str, output_formats=("html",),
              template_dir="./brand-templates", ...)

Template resolution order

The explicit template_dir is searched first, ahead of the implicit paths already wired up by previous PRs:

  1. --template-dir / parse template_dir (explicit, this PR)
  2. YAML source directory (source_path.parent) — from Fix template search path wireviz/WireViz#473
  3. Output directory — existing
  4. WireViz built-in templates — fallback

Differences from upstream PR wireviz#444

Verification

  • build_examples.py runs clean across all 14 examples + 8 tutorials + 2 demos; deterministic outputs (.gv, .bom.tsv) byte-identical to baseline.
  • Manual smoke-test: a branded.html template living only in a -t directory (not next to the YAML, not in the output dir) resolves correctly and renders. Absence of -t produces a clean \"branded.html was not found in any of the following locations\" error from smart_file_resolve.

Test plan

  • CI workflow passes
  • wireviz -t /some/dir harness.yml renders with custom template
  • Reviewer to verify naming choice (template_dir vs templatedir)

🤖 Generated with Claude Code

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>
Copy link
Copy Markdown

@gemini-code-assist gemini-code-assist Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread src/wireviz/Harness.py
cleanup: bool = True,
output_dir: Optional[Union[str, Path]] = None,
output_name: Optional[str] = None,
template_dir: Optional[Union[str, Path]] = None,
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The template_dir parameter is missing from the output method's docstring. Please update the docstring to include a description of this new parameter, explaining that it specifies an explicit directory to search for HTML templates.

Comment thread src/wireviz/Harness.py
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,
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The template_dir parameter is missing from the _render method's docstring. Adding it will improve the internal documentation of the class and maintain consistency with the other methods in this file.

Comment thread src/wireviz/wireviz.py
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,
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The new template_dir parameter should be documented in the parse function's docstring under the Args: section. This is important for users of the Python API to understand how to use the new functionality.

@SomethingNew71
Copy link
Copy Markdown
Author

@tbornon-sts — heads up, your upstream #444 (--template-dir option) is being incorporated here.

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 wireviz/WireViz looks abandoned (no real master activity since the v0.4.1 release in 2021), so we're forking and pulling in the useful open PRs.

--template-dir lines up well with our GUI plans — we want to ship branded HTML chrome that lives outside the YAML source tree. Two minor cleanups in this port worth flagging:

  • The kwarg name was unified to template_dir everywhere (the upstream patch had templatedir on the kwarg vs template_dir on the CLI option).
  • Dropped the leftover print("Test") debug line that was in the upstream diff.

Search order ended up as: explicit template_dir → YAML source dir → output dir → built-in templates, which integrates cleanly with the other PRs we're pulling in.

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>
@SomethingNew71 SomethingNew71 merged commit a658cc7 into port-321-stdin-stdout May 5, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant