DCC Integration¶
Each DCC is its own self-contained workspace package under packages/<dcc>/src/kpipe_<dcc>/,
following a three-layer pattern within that one package.
Layers¶
1. Launcher (packages/<dcc>/src/kpipe_<dcc>/launcher.py)¶
- Reads the DCC executable path from config
- Sets environment variables:
PYTHONPATH,OCIO,KPIPE_ENV, etc. - Spawns the DCC process
Run from the command line:
2. Extension (sibling files in kpipe_<dcc>/)¶
Startup scripts loaded by the DCC when it launches, packaged alongside the launcher in the same directory. Responsibilities:
- Import and initialise the K-Pipe session
- Register DCC-specific actions into the action registry
- Add K-Pipe menus or panels to the DCC UI
Blender uses the Blender 4+ extension system (kpipe_blender/system/, containing both
the kpipe_blender extension and the integrated kpipe_asset_pipeline extension as
sibling installable extensions — required so Blender's local extension repository scan
sees both). Nuke uses a menu.py/init.py startup script pair, found by pointing
NUKE_PATH/NUKE_MENU_PATH at the package directory itself
(Path(__file__).resolve().parent from launcher.py, since launcher and extension files
are always siblings in this layout).
3. Session (kpipe.session, in packages/core/src/kpipe/session.py)¶
- Manages the active entity and task state
- Extensions register DCC-specific callbacks for open, save, and close events
- Handles versioned workfile naming on save
Adding a new DCC¶
- Create
packages/<dcc>/with asrc/kpipe_<dcc>/tree containinglauncher.pyplus the DCC's startup/extension scripts - Register the launcher as a script entry point in
packages/<dcc>/pyproject.toml([project.scripts], e.g.kpipe-<dcc> = "kpipe_<dcc>.launcher:main") - Add
packages/<dcc>to the rootpyproject.toml's[tool.uv.workspace] members - Add DCC path config key to your project bundle's
kpipe.toml