Documentation Download

Kibo templates for Viper

kibo-template-viper 2 turns a DSM model into a typed Python package, matching C++ surfaces and a typed TypeScript package — one namespace of the model, one unit of each.

The pack's features Source on GitHub
3 Surfaces from One Model C++, Python and TypeScript, from the same DSM input
1 Unit per Namespace A C++ namespace, a Python module, a TypeScript directory for each DSM namespace
à la carte Feature Selection Each target lists its features in the project's kibo.toml

Where it sits in the pipeline

The template pack is not a tool you run. It is what Kibo renders when targeting the Viper runtime. A project names its features in a kibo.toml, and kibo_project.py resolves them into the pack's templates.

1

DSM

model.dsm
→
2

Project

kibo.toml
→
3

Template

cpp | python | typescript
→
4

Output

*.hpp/cpp + *.py + *.ts

Static typed code, dynamic runtime

Viper is a dynamic, metadata-driven engine, strongly typed at runtime through its definitions. Without a typed surface, every field access goes through string lookups: no autocomplete, no rename refactor, typos caught only at runtime. The pack emits a statically typed surface that mirrors your DSM, while the data underneath stays the same Viper value.

Developer reality

What your editor sees: classes, fields, enums, methods, all named after your DSM model.

  • Autocomplete and go-to-definition in any IDE
  • Type checking before you run anything
  • Rename refactor across the whole codebase
  • The same surface in Python and TypeScript, each in its own idiom

Runtime reality

What actually executes: the dynamic Viper value tree with its metadata, mutation DAG, attachments, and dispatch.

  • A generated object boxes one Viper value; it does not copy it
  • RPC, persistence, and serialization through the runtime
  • The surface is generated, never hand-written
  • Schema changes regenerate it — no migration code

Three surfaces, one source of truth

Pick C++, Python, TypeScript, or any combination. The surfaces you take stay in lock-step by construction — same DSM source, no manual proxy code, no drift between languages. Below, <ns> is a DSM namespace and <pool> a function pool.

C++ surfaces

Headers and implementations linking against the Viper C++ engine, through its static layer — for embedding inside a native application.

  • <ns>_data, <ns>_model — types and their definitions
  • <ns>_codec — to and from Viper values
  • <ns>_fields — every field's name and path
  • <ns>_attachments — attachments, by the concept they are keyed on
  • <pool>_pool, <pool>_remote — function pools, server and client sides

Python package

A fully annotated package, usable through the dsviper for Python runtime.

  • <ns>/data.py — concepts, clubs, enumerations, structures
  • <ns>/attachments.py — attachments, by concept
  • containers.py — the typed containers the model uses
  • <pool>/pool.py — a pool's local and remote classes
  • pyproject.toml — ready to pip install as a wheel

TypeScript package

An npm package of typed classes over the dsviper Node binding, compiling under --strict — the TypeScript counterpart of the Python package.

  • <ns>/data.ts — concepts, clubs, enumerations, structures
  • <ns>/attachments.ts — attachments, by concept
  • containers.ts — the typed containers the model uses
  • pools.ts — typed remote clients (over ServiceRemote)
  • package.json, tsconfig.json — a ready-to-build package

Remote clients only — a Node back-end consumes pools, it doesn't host local ones.

Pack contents

Features per target, each opt-in in a project's kibo.toml; a feature brings what it depends on (Attachments brings Paths, which brings Fields).

C++

Base, Fields, Paths, Attachments, Pool, PoolRemote.

Python

Base, Fields, Paths, Attachments, Pool, Wheel.

TypeScript

Base, Fields, Paths, Attachments, Pool, Package.

Distribution and source

In the DevKit ZIP

In kibo-2/templates/, beside the Kibo jar it requires, and driven by tools/kibo_project.py. No separate install — pulled from /downloads with the rest of DevKit.

On GitHub

digital-substrate/kibo-template-viper — public source repository. Open template format, so a third-party pack can target any other runtime (e.g. kibo-template-django, kibo-template-protobuf).

The 1.2 pack is deprecated. kibo-template-viper 1.2, for kibo 1, receives fixes only, for the life of the LTS-1.2 line; it stays in the DevKit, in kibo-1/templates/, for existing projects — migrating to Kibo 2.

Generate Your First Package

Describe the generation in a kibo.toml, then package the typed output as a Python wheel or an npm package.

kibo-project Build a Wheel Build an npm Package