geti-library-dev

name

geti-library-dev

description

Develop and validate changes in `library/` for the `getitune` Python package (the Geti training library). Use when touching `library/src/**`, `library/tests/**`, `library/pyproject.toml`, recipes, model manifests, or any Python API, CLI, model, training, export, or utility logic owned by the library. Helps with `uv` and `just` setup, choosing cpu, cuda, or xpu extras, the multi-backend model architecture, adding models and recipes, and running the smallest relevant lint, unit, model, or integration checks.

Geti Library Development

For the full architecture reference (package layout, multi-backend design, how to add models, recipes, and manifests) read library/AGENTS.md.

Quick Start

• Work from library/.
• Create or refresh the environment with just venv --device cpu for routine work.
• Switch to just venv --device cuda or just venv --device xpu only when the task needs accelerator-specific behavior.
• Run just lint before wider test runs.

Architecture Essentials

• Source lives under src/getitune/. Public API entry points must stay stable because application/backend/ consumes them.
• Multi-backend design: compute backends live under src/getitune/backend/ — lightning/ (PyTorch Lightning training), openvino/ (inference-only), and optional ultralytics/. src/getitune/models/ re-exports model classes from each backend into one namespace.
• Device abstraction: DeviceType (src/getitune/types/device.py) and DeviceConfig (src/getitune/config/device.py) abstract accelerator choice. Guard device-specific (CUDA vs XPU) code with capability checks in src/getitune/utils/device.py — never at import time.
• Recipes: YAML configs under src/getitune/recipe/<task>/<model>.yaml bind a task + model class_path + training config. Recipes are self-discovering via src/getitune/utils/recipes.py (list_models) — no registry to update.
• Adding a model: implement the model class under src/getitune/backend/lightning/models/<task>/, inheriting the task base class (ultimately LightningModel); export it from the task __init__.py; add a recipe YAML. See library/AGENTS.md for the full walkthrough.

Workflow

1. Confirm the change belongs in library/. If the task is mainly FastAPI or React work, switch to the matching backend or UI skill.
2. Inspect the nearest module and tests before editing. Keep changes inside the existing package boundaries under src/getitune/.
3. Make the smallest change that resolves the task. Avoid lockfile churn unless dependencies changed intentionally.
4. Run the smallest relevant checks first and widen only if the changed behavior crosses package or task boundaries.

Verification

• Use just lint for formatting, lint, and type issues.
• Use just test-unit -- tests/unit/... or just test-unit -- -k <expr> for normal Python behavior changes.
• Use just test-unit-models -- <pytest args> for model-specific code.
• Use just test-integration -- <pytest args> only when the change affects end-to-end training, export, or integration behavior.

Coordination Notes

• application/backend consumes ../../library as a local editable dependency. If the change affects shared runtime behavior, validate the backend too.
• Update docs or examples when public library behavior changes.
• Prefer project just targets over ad hoc dependency-install commands so the pinned uv workflow stays consistent with CI.