Summary
ij/__init__.py declares __version__ = "0.2.0", while pyproject.toml and the published PyPI release are at 0.1.5. Anything reading ij.__version__ reports a version that does not exist on PyPI.
Why it drifted
The wads CI auto-bumps the version in pyproject.toml and pushes the bump back to the default branch. It does not touch a hardcoded __version__ in __init__.py, so a manually-set dunder silently diverges and keeps diverging with every release.
Suggested fix
Do not hardcode it — derive it from installed metadata so there is a single source of truth:
from importlib.metadata import version, PackageNotFoundError
try:
__version__ = version("ij")
except PackageNotFoundError: # not installed (e.g. running from a source checkout)
__version__ = "unknown"
Alternatively drop __version__ entirely and let consumers use importlib.metadata.version("ij").
Whichever is chosen, the fix is worth applying as a fleet pattern — any repo in the ecosystem with a hardcoded __version__ will drift the same way under CI auto-bump.
Surfaced during the 2026-07-30 wave-0 rollout batch.
Summary
ij/__init__.pydeclares__version__ = "0.2.0", whilepyproject.tomland the published PyPI release are at0.1.5. Anything readingij.__version__reports a version that does not exist on PyPI.Why it drifted
The wads CI auto-bumps the version in
pyproject.tomland pushes the bump back to the default branch. It does not touch a hardcoded__version__in__init__.py, so a manually-set dunder silently diverges and keeps diverging with every release.Suggested fix
Do not hardcode it — derive it from installed metadata so there is a single source of truth:
Alternatively drop
__version__entirely and let consumers useimportlib.metadata.version("ij").Whichever is chosen, the fix is worth applying as a fleet pattern — any repo in the ecosystem with a hardcoded
__version__will drift the same way under CI auto-bump.Surfaced during the 2026-07-30 wave-0 rollout batch.