Architecture Overview¶

K-Pipe is a uv workspace of self-contained packages under packages/. Each package owns its full source tree under its own src/ (e.g. packages/core/src/kpipe/, packages/nuke/src/kpipe_nuke/) — there is no shared top-level lib//scripts// extensions//res/ tree. The core library (kpipe) lives in packages/core/src/kpipe/; optional DCC packages (e.g. kpipe_blender, kpipe_nuke) each bundle their own launcher and DCC extension together.

Key modules¶

Module	Location	Role
`config.py`	`packages/core/src/kpipe/`	Loads TOML configs; resolves `team.<username>` overrides
`entity.py`	`packages/core/src/kpipe/`	`Entity`, `EntityData` (metadata TOML), `EntityFileHelper` (naming)
`production.py`	`packages/core/src/kpipe/`	`ProductionManager` singleton; file-locked TOML cache (30-min TTL)
`attributes.py`	`packages/core/src/kpipe/`	Config queries — FPS, handles, product/output/format definitions
`publish.py`	`packages/core/src/kpipe/`	`integrate_file/video/sequence()` — copies outputs into publish tree
`pipeline.py`	`packages/core/src/kpipe/`	Four-phase publish workflow and action registry
`session.py`	`packages/core/src/kpipe/`	DCC workfile lifecycle with DCC-specific callbacks
`path.py`	`packages/core/src/kpipe/`	Template-based path resolution

DCC integration pattern¶

Each DCC follows a three-layer pattern:

Launcher script        →  resolves DCC install path, sets env vars, spawns DCC
  └─ Extension         →  startup scripts loaded by the DCC, initialises K-Pipe context
       └─ Session      →  manages active entity/task; DCC registers open/save/close callbacks

See DCC Integration for details.

Production backend¶

ProductionManager abstracts the data source via ProductionBackend. The only implemented backend is Kitsu (packages/kitsu/src/kpipe_kitsu/backend.py) using the gazu SDK. Results are cached locally in a TOML file with filelock for multi-process safety.

Set data_backend = "kitsu" (or "local") in the project config.