Problem
pyproject.toml declares py.typed as package data (PEP 561), and mypy>=1.17 is in the dev dependencies. CI runs mypy --strict examples/typed_consumer.py — one example file. However:
- The library code itself is not type-checked by mypy in CI.
mypy --strict lib/python/base_cli/ is not run anywhere in the test or package workflows.
- There is no
[tool.mypy] section in pyproject.toml. Downstream users who run mypy on their own code and use base-cli have no guidance on what mypy configuration is compatible.
For a package that ships py.typed and promises typed public APIs, not running mypy on the library itself is a gap. Type errors in the library's own code would not be caught until a consumer's mypy run fails.
Fix
- Add a
[tool.mypy] section to pyproject.toml:
[tool.mypy]
python_version = "3.10"
strict = true
warn_unused_ignores = true
- Add a mypy check to the CI tests workflow:
- name: Type-check library
run: python -m mypy --strict lib/python/base_cli/
- Resolve any mypy errors this surfaces (common ones: missing stubs for optional deps like
rich, opentelemetry-api — these can be conditioned with TYPE_CHECKING guards).
Problem
pyproject.tomldeclarespy.typedas package data (PEP 561), andmypy>=1.17is in the dev dependencies. CI runsmypy --strict examples/typed_consumer.py— one example file. However:mypy --strict lib/python/base_cli/is not run anywhere in the test or package workflows.[tool.mypy]section inpyproject.toml. Downstream users who run mypy on their own code and usebase-clihave no guidance on what mypy configuration is compatible.For a package that ships
py.typedand promises typed public APIs, not running mypy on the library itself is a gap. Type errors in the library's own code would not be caught until a consumer's mypy run fails.Fix
[tool.mypy]section topyproject.toml:rich,opentelemetry-api— these can be conditioned withTYPE_CHECKINGguards).