version: derive __version__ from the dist, stop keeping a second copy#11
Merged
Conversation
__version__ said "0.1.2" while the distribution said 0.2.1 — two releases stale. It is in __all__, so it is public API, and anything branching on chiplog.__version__ got a wrong answer. It was a hand-written literal that every release had to remember to touch, and two releases in a row did not. The fix is not to touch it more carefully. 0.2.1 just finished learning this shape on the NON-CLAIMS block: "keep the version numbers accurate" is not a rule that holds, because the docs and the code move on different schedules. The rule that holds removes the second copy. So the number now lives once, in the packaging config, and __init__ derives it from the installed dist metadata. The guard test asserts what the package exports is what the package is — comparing against pyproject.toml, so it stays honest under either implementation. Not in scope, filed separately: src/ carries five more stale "v0.1" prose references (sinks/base.py says v0.1 ships only the LocalFileSink; v0.2 also does), and SCOPE_STATEMENT.md is still stamped v0.1 under a line reading "Written BEFORE the code so we don't drift". Each needs its own judgement — cli.py's "identical semantics to v0.1" is legitimate history, not drift.
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.
__init__.py:40said__version__ = "0.1.2"while the distribution was 0.2.1 — two releases stale. It is in__all__, so it is public API, and anything branching onchiplog.__version__got a wrong answer.Why derive rather than guard a literal
The obvious fix is to correct the literal and add a test that it matches. This PR does not do that, and the reason is a lesson this repo learned six commits ago.
0.2.1 fixed a NON-CLAIMS block that named releases it should not have, and the finding there was that "keep the version numbers accurate" is not a rule that holds — the docs and the constants move on different schedules, and two separate correction passes had already missed the same string. The enforceable rule was the one that removed the chance to be wrong.
Same shape here. A literal plus a test is still two copies of the number, with a reminder attached. Deriving from the packaging config leaves one copy and no reminder to forget.
What changes
__version__derives from installed dist metadata;pyproject.tomlis the one place the number lives.tests/test_version_single_source.pyasserts the exported version equals the packaged version, read frompyproject.toml— non-tautological, and valid under either implementation.No behaviour change beyond
__version__reporting the truth.Found, and not fixed here
src/carries five more stalev0.1prose references, andSCOPE_STATEMENT.mdis still stampedv0.1beneath a line reading "Written BEFORE the code so we do not drift". They are a mix —sinks/base.py's "v0.1 ships only the LocalFileSink" is stale (v0.2 also does), whilecli.py's "identical semantics to v0.1" is legitimate history. Each needs its own judgement, so they are filed separately rather than swept in here.Reported from the bosun migration, 2026-07-17.