fix: read __version__ from distribution metadata - #50
Merged
Conversation
`__version__` was a second hardcoded literal alongside `pyproject.toml` and
never moved, so it sat at "0.2.0" through both the 0.3.0 and 0.4.0 releases.
`cli.py` passes it to `@click.version_option`, so:
$ trace-tests --version
trace-tests, version 0.2.0 # from a 0.4.0 install
$ python -c "import importlib.metadata as m; \
print(m.version('agentrust-trace-tests'))"
0.4.0
Worse than a cosmetic slip. The v0.2 profile cutover shipped in 0.4.0 and a
0.2.x suite rejects every v0.2 record, so `--version` is precisely the command
someone runs to work out whether their suite matches their producer. It was the
one command that could not answer, and it actively misled: a correctly upgraded
user is told they still have the version that cannot verify their records.
Found while running the suite against a freshly minted record: the record failed
TR-ENV on the profile sentinel, and `--version` reported 0.2.0 both before and
after upgrading to 0.4.0, so it gave no signal that the upgrade had worked.
Fix reads the version from installed distribution metadata, removing the
duplicate literal so it cannot fall behind a release again. Stdlib only, no new
dependency. A source tree importable without an install has no metadata to read,
so that falls back to "0.0.0+unknown" rather than guessing a number and
reintroducing the drift.
Two regression tests: `--version` output must contain the distribution version,
and `__version__` must equal it, which fails if anyone restores a literal.
Verified: `pip install -e .` then `trace-tests --version` -> 0.4.0.
Full suite 118 passed, 5 xpassed (the 5 are pre-existing
`xfail(strict=False)` hardware-TEE cases in tests/test_level2.py, untouched).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
imran-siddique
added a commit
that referenced
this pull request
Aug 3, 2026
Patch release carrying the `--version` fix from #50. 0.4.0 reports `0.2.0` from `trace-tests --version`, which matters because the v0.2 profile cutover shipped in 0.4.0: `--version` is the command someone runs to check whether their suite matches their producer, and on 0.4.0 it answers with the version that cannot verify v0.2 records. The fix is on main but not on PyPI, so every installer still hits it until this ships. No behaviour change to conformance checking. The v0.2 profile requirement, module set, and every finding are identical to 0.4.0. Verified after the bump: - `trace-tests --version` -> 0.4.1, `importlib.metadata` -> 0.4.1. The version now tracks pyproject.toml with no code change, which is the point of #50. - `python -m pytest tests -q` -> 118 passed, 5 xpassed (pre-existing hardware-TEE xfails in tests/test_level2.py). - `python -m build` -> agentrust_trace_tests-0.4.1 sdist and wheel. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
__version__was a second hardcoded literal alongsidepyproject.tomland never moved, so it sat at0.2.0through both the 0.3.0 and 0.4.0 releases.cli.pyfeeds it to@click.version_option, so a 0.4.0 install reports 0.2.0:This is worse than a cosmetic slip. The v0.2 profile cutover shipped in 0.4.0, and a 0.2.x suite rejects every v0.2 record, so
--versionis exactly the command someone runs to work out whether their suite matches their producer. It was the one command that could not answer, and it misled in the harmful direction: a correctly upgraded user is told they still have the version that cannot verify their records.How it surfaced: a freshly minted record failed
TR-ENVon the profile sentinel, and--versionprinted0.2.0both before and after upgrading to 0.4.0, so it gave no signal that the upgrade had worked. The real version had to be recovered withimportlib.metadata.What changed
src/trace_tests/__init__.py: read the version from installed distribution metadata instead of restating it.pyproject.tomlis what the build and PyPI publish, so it is now the single source of truth and this value cannot fall behind a release again. Stdlib only, no new dependency.0.0.0+unknownrather than guessing a number, which would reintroduce exactly the drift this removes.tests/unit/test_cli.py: two regression tests. One asserts--versionoutput contains the distribution version; the other asserts__version__equals it, which fails if anyone restores a hardcoded literal.CHANGELOG.md: entry under Unreleased.Fixing the constant to
0.4.0would have worked until the next release. This removes the class of bug instead.Test plan
pip install -e .thentrace-tests --version->trace-tests, version 0.4.0python -m pytest tests -q-> 118 passed, 5 xpassedThe 5 xpassed are pre-existing
xfail(strict=False)hardware-TEE cases intests/test_level2.py, untouched by this change.🤖 Generated with Claude Code