Contributing¶
This page covers the standard PR workflow for the OmniRT repo — dev setup, tests, and documentation conventions.
Dev environment¶
git clone https://github.com/datascale-ai/omnirt.git
cd omnirt
# Dev deps
python -m pip install -e '.[dev]'
# Add extras only when needed
python -m pip install -e '.[runtime,dev]' # real inference
python -m pip install -e '.[server,dev]' # FastAPI server
python -m pip install -e '.[docs]' # docs site
Recommended Python: 3.11 (matches CI; 3.10+ should also work).
pre-commit¶
The sole current hook is generate-models-doc: it regenerates docs/user_guide/models/supported_models.md whenever you touch src/omnirt/core/registry.py, src/omnirt/models/**, or that doc, and runs --check so drift is caught before review.
Local tests¶
Covers low-VRAM, bad-weight, incompatible-adapter, and other failure paths.
Hardware smoke tests skip automatically when prerequisites / model sources / hardware are missing.
Documentation¶
The docs CI (docs-lint job) runs three things in order:
scripts/generate_models_doc.py --check— the registry doc is up to datescripts/check_bilingual_parity.py— every Chinese page has an English sibling and lengths look reasonablemkdocs build --strict— all links, references, and nav entries are valid
Reproduce locally:
python -m pip install -e '.[dev,docs]'
python scripts/generate_models_doc.py --check
python scripts/check_bilingual_parity.py
mkdocs build --strict
Bilingual convention: the Chinese source is foo.md and its English sibling is foo.en.md. See Publishing Docs.
PR workflow¶
- Fork → branch: use
feat/xxx,fix/xxx, ordocs/xxxnaming - Commit messages: first line ≤ 72 chars, imperative mood; the body explains why
- Test coverage: new public behavior must ship with
tests/unitortests/paritycases; hardware-specific features need at least one skippable smoke - Docs: update
docs/whenever public API, request schema, or model support changes - Open the PR: describe motivation and scope; paste the output of
pytest tests/unit tests/parity --maxfail=1
Extension points¶
- New model → read Model Onboarding
- New backend → read Backend Onboarding
- New task surface → touch
omnirt.core.types+omnirt.core.validation+omnirt.requests; open an ADR first - New feature (preset, adapter kind, etc.) → spell out the motivation and trade-offs in the PR description; when alignment matters, socialize in a GitHub issue or Discussion first
References¶
- Architecture — repo layout and the current runtime topology
- Model Onboarding —
@register_model+ModelCapabilities - Backend Onboarding —
BackendRuntime.wrap_modulecontract - pyproject.toml — extras and entry points