Problem
harness.Report lays its table out with printf field widths chosen by eye:
// internal/harness/harness.go:165
_, _ = fmt.Fprintf(&b, "%-40s %-20s %s\n", r.Spec, r.Outcome, r.Detail)
r.Spec is a spec path, and almost every path in the repo is longer than 40 characters,
so the outcome column is not a column at all. Measured on main @ dbf0054:
$ git ls-files 'testdata/*' | awk 'length($0) > 40' | wc -l
168 # of 177 tracked testdata paths
$ go run ./cmd/morphic-harness testdata/conformance/openapi | head -3
testdata/conformance/openapi/allof-boolean-branch.yaml ok
testdata/conformance/openapi/allof-inheritance.yaml ok
testdata/conformance/openapi/allof-inline-merge.yaml ok
The oks land wherever the path happens to end, and the trailing %-20s pads every line
with spaces the report has no use for. Both widths should be derived from the results
being rendered, the way writeCommandList derives the CLI's command column.
Why it is filed rather than fixed
This is the same defect as #232 — a printf field width sized against today's data — and it
was found by sweeping that mechanism. #232's own site was fixed alongside the validate
subcommand (#81), because the CLI help table, the subcommand and the shared dispatch are
one change; the harness report is a different package, a different consumer, and its output
is a developer-facing tool report rather than program output, so folding it in would have
meant one PR carrying two unrelated changes.
Unlike #232's site this one is not latent. It is misaligned today, for most of the corpus.
Problem
harness.Reportlays its table out with printf field widths chosen by eye:r.Specis a spec path, and almost every path in the repo is longer than 40 characters,so the outcome column is not a column at all. Measured on
main@dbf0054:The
oks land wherever the path happens to end, and the trailing%-20spads every linewith spaces the report has no use for. Both widths should be derived from the results
being rendered, the way
writeCommandListderives the CLI's command column.Why it is filed rather than fixed
This is the same defect as #232 — a printf field width sized against today's data — and it
was found by sweeping that mechanism. #232's own site was fixed alongside the
validatesubcommand (#81), because the CLI help table, the subcommand and the shared dispatch are
one change; the harness report is a different package, a different consumer, and its output
is a developer-facing tool report rather than program output, so folding it in would have
meant one PR carrying two unrelated changes.
Unlike #232's site this one is not latent. It is misaligned today, for most of the corpus.