fix: derive __version__ from package metadata#2
Merged
Conversation
The publish workflow's `uv version --bump` step only edits
`pyproject.toml`, but `__version__` was a hand-kept constant in
`__init__.py`. After the v0.2.0 release the wheel's metadata said
`0.2.0` while `commonlid.__version__` and every `summary.json`'s
`commonlid_version` field stayed at `0.1.0`.
Make `pyproject.toml` the single source of truth: read the version
from `importlib.metadata.version("commonlid")` at import time, with a
sentinel fallback for un-installed source-tree imports. Lives in a new
`_version.py` to keep `__init__.py` lint-clean (RUF067 forbids
runtime statements there).
Add a regression test asserting `commonlid.__version__` equals
`importlib.metadata.version("commonlid")` so any future drift is
caught by the standard gate run instead of in production.
Co-Authored-By: Claude Opus 4.7 (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.
Summary
After the
v0.2.0release the wheel's metadata correctly said0.2.0, butcommonlid.__version__(and thereforecommonlid version, andsummary.json["commonlid_version"]) still reported0.1.0. Root cause: the publish workflow's bump step (uv version --bump …) only editspyproject.toml;src/commonlid/__init__.pycarried a hand-kept__version__ = "0.1.0"that nothing in CI updates. The release commita8656dd(chore(release): v0.2.0) only touchespyproject.toml+uv.lock, so the constant went stale.This PR makes
pyproject.tomlthe single source of truth:__version__is now read fromimportlib.metadata.version("commonlid")at import time, with a sentinel fallback ("0.0.0+unknown") for un-installed source-tree imports (e.g.PYTHONPATH=src python …). The mismatch can no longer happen.The version-derivation lives in a tiny new
src/commonlid/_version.pyso__init__.pystays lint-clean — RUF067 forbids runtime statements (thetry/except) in package__init__.Files
src/commonlid/_version.py(new) — reads version fromimportlib.metadata.src/commonlid/__init__.py— re-export__version__from_version.tests/unit/test_cli_stub.py— new regression test:Test plan
make lint(ruff)make format-checkmake typecheck(mypy strict)make test— 231 passed, 39 deselected, 94.60% coverage (1 new test)commonlid.__version__→0.2.0, matchingimportlib.metadata.version("commonlid")test_versionstill passes (CLI prints whatever__version__is)Follow-up note (out of scope)
This PR fixes the runtime constant going forward, but
commonlid==0.2.0on PyPI right now still ships the stale0.1.0constant. The fix is user-visible only after a version bump + new release. No action needed beyond the next release.🤖 Generated with Claude Code