Files
LEDMatrix/CONTRIBUTING.md
T
ChuckandClaude Opus 5.5 b8c01c69fb ci: mypy ratchet -- keep type-clean modules clean (71 modules, 536 -> 442 errors) (#661)
* ci: mypy ratchet -- keep type-clean modules clean

mypy-clean.txt lists the 71 modules under src/ that type-check clean;
scripts/check_types.py runs mypy (--follow-imports=silent) on exactly
those files and fails on any error or a missing/unsorted/duplicate entry.
A new "Type check (mypy ratchet)" CI job runs it with mypy 1.20.2 and
pinned stubs; the manual pre-commit mypy hook now runs the same script
(a local hook, so mypy sees the installed requirements like CI does).

35 modules were made clean with annotation-only fixes: hints, typing.cast,
TYPE_CHECKING imports, implicit-Optional defaults made explicit, and
annotations widened (never guards removed) where mypy called a defensive
isinstance check unreachable. No runtime behaviour change.

mypy.ini: numpy and orjson are treated as Any (follow_imports=skip, also
for stubs). numpy 2.3+ stubs use 3.12 `type` statements that mypy won't
parse at python_version 3.10, and orjson is optional, so seeing its stubs
made the result depend on whether it was installed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* chore: annotate check_types.py's list-form mypy subprocess

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 15:01:35 -04:00

4.8 KiB

Contributing to LEDMatrix

Thanks for considering a contribution! LEDMatrix is built with help from the community and we welcome bug reports, plugins, documentation improvements, and code changes.

Setting up a development environment

  1. Clone with submodules:
    git clone --recurse-submodules https://github.com/ChuckBuilds/LEDMatrix.git
    cd LEDMatrix
    
  2. For development without hardware, run the dev preview server:
    python3 scripts/dev_server.py
    # then open http://localhost:5001
    
    See docs/DEV_PREVIEW.md for details.
  3. To run the full display in emulator mode:
    EMULATOR=true python3 run.py
    
  4. To target real hardware on a Raspberry Pi, follow the install instructions in the root README.md.

Running the tests

pip install -r requirements.txt -r requirements-test.txt
pytest

See docs/HOW_TO_RUN_TESTS.md for details on test markers, the per-plugin tests, and the web-interface integration tests.

Submitting changes

  1. Open an issue first for non-trivial changes. This avoids wasted work on PRs that don't fit the project direction.
  2. Create a topic branch off main: feat/<short-description>, fix/<short-description>, docs/<short-description>.
  3. Keep PRs focused. One conceptual change per PR. If you find adjacent bugs while working, fix them in a separate PR.
  4. Follow the existing code style. The pre-commit hooks run flake8 (E9, F63, F7, F82 plus bugbear B checks), bandit, and gitleaks — install the CLI with python -m pip install pre-commit, then run pre-commit install so they run on every commit. Type checking is a ratchet while the existing mypy errors in src/ are paid down: mypy-clean.txt lists the modules that type-check clean, and CI runs python scripts/check_types.py (also the manual hook pre-commit run mypy --hook-stage manual) to keep every listed module clean. When you make another module clean, add it to the list (sorted); don't take one off to get CI green. Keep type fixes annotation-only where you can -- widen a hint rather than delete a defensive runtime check mypy calls unreachable. HTML/JS in web_interface/ follows the patterns already in templates/v3/ and static/v3/.
  5. Update documentation alongside code changes. If you add a config key, document it in the relevant *.md file (or, for plugins, in config_schema.json so the form is auto-generated).
  6. Run the tests locally before opening the PR.
  7. Use the PR template — .github/PULL_REQUEST_TEMPLATE.md will prompt you for what we need.

Commit message convention

Conventional Commits is encouraged but not strictly enforced:

  • feat: add NHL playoff bracket display
  • fix(plugin-loader): handle missing class_name in manifest
  • docs: correct web UI port in TROUBLESHOOTING.md
  • refactor(cache): consolidate strategy lookup

Keep the subject under 72 characters; put the why in the body.

Contributing a plugin

LEDMatrix plugins live in their own repository: ledmatrix-plugins. Plugin contributions go through that repo's SUBMISSION.md process. The hello-world plugin is the canonical starter template.

Reviewing pull requests

Maintainer review is by @ChuckBuilds. Community review is welcome on any open PR — leave constructive comments, test on your hardware if applicable, and call out anything unclear.

Code of conduct

This project follows the Contributor Covenant. By participating you agree to abide by its terms.

License

LEDMatrix is licensed under the GNU General Public License v3.0 or later. By submitting a contribution you agree to license it under the same terms (the standard "inbound = outbound" rule that GitHub applies by default).

LEDMatrix builds on rpi-rgb-led-matrix, which is GPL-2.0-or-later. The "or later" clause makes it compatible with GPL-3.0 distribution.