Skip to content

feat: stamp the tool version into measurement files and reports - #20

Open
repentsinner wants to merge 1 commit into
mainfrom
feat/stamp-tool-version
Open

feat: stamp the tool version into measurement files and reports#20
repentsinner wants to merge 1 commit into
mainfrom
feat/stamp-tool-version

Conversation

@repentsinner

Copy link
Copy Markdown
Member

Reports from this tool get shared and compared across vendors. The tolerance bands, the dE ITP math, and the primary-matrix estimator all change between versions — so a report that cannot say which build produced it undercuts the "open and independently verifiable" claim directly.

Removes a false provenance record

The anonymizer was writing the name of a different project into every file it touched:

# strip_metadata.py — before
file_data.metadata = CSMF_Metadata(software="colour-workbench file stripper")

colour-workbench is the project this code was extracted from years ago — the same lineage as the ole/ETC naming already cleaned up. Any file passed through the anonymizer carries that string today. Meanwhile analyze --strip-details wrote software=None, discarding provenance entirely.

Both now record the real tool. The version identifies the code, not the measurement subject, so keeping it through anonymization leaks nothing.

What's added

display_report.utilities.tool_identifier()"display-report 0.1.0", written to CSMF_Metadata.software on every path that builds measurement metadata:

Path Before After
--device-name supplied unset stamped
interactive wizard unset stamped
non-interactive default unset stamped
DeviceInfo.to_metadata() unset stamped
analyze --strip-details None stamped
anonymize "colour-workbench file stripper" stamped

Plus a small right-aligned label on the report header, so the PDF itself carries the version rather than only the source file.

Version source

Resolved through importlib.metadata, so it reads the static pyproject version today (0.1.0) and switches to tag-derived hatch-vcs versions once build/flywheel-and-main-rename lands. No ordering dependency between the two PRs — this works either way. A PackageNotFoundError fallback covers running from an uninstalled source tree, and a test asserts the fallback is not what CI resolves.

Verification

ruff format --check    21 files already formatted
ruff check             All checks passed!
pyright                0 errors, 0 warnings, 0 informations
cspell                 0 issues in 0 files
pytest                 40 passed  (31 existing + 9 new)

Two things worth knowing

A bug here was caught by ruff, not by the tests. My first patch put tool_identifier into the wrong import block, leaving F821 Undefined name inside the --strip-details branch. Tests stayed green because that branch has no coverage.

Which is the real gap: this repo has zero .csmf fixtures. analyze and anonymize cannot be exercised end to end at all, so the two paths this PR touches in those scripts are covered only by the linter. Worth adding a small anonymized fixture — anonymize exists precisely to produce shareable ones.

Reports are compared across vendors, and the tolerances, metrics, and
primary-matrix estimator all change between versions. A report that
cannot say which build produced it undercuts the reproducibility the
project claims.

Adds display_report.utilities.tool_identifier() and writes it to
CSMF_Metadata.software on every path that builds measurement metadata,
and onto the report header.

Removes a false provenance record. The anonymizer hardcoded
software="colour-workbench file stripper" — naming the project this code
was extracted from, not this one — and analyze --strip-details wrote
software=None. Both now record the real tool. The tool version identifies
the code, not the measurement subject, so keeping it through
anonymization leaks nothing.

The version resolves through importlib.metadata, so it reads the static
pyproject version today and tag-derived hatch-vcs versions once
build/flywheel-and-main-rename lands. No coupling either way.
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