--- title: "Runtime Delivery" description: "How each SDK obtains and loads the native OpenPit runtime." --- # Runtime Delivery How each SDK obtains and loads the native OpenPit runtime. The engine core is one native library. Every SDK either embeds it, ships it inside its package, or resolves it at configure time, so a normal installation needs no extra step. This page describes where the runtime comes from in each language and which environment variables override that choice. Overrides exist for three situations: developing against a locally built runtime, running in an environment with no outbound network access, and pinning one shared library for a fleet of processes. Application code never needs them. ## Go The native runtime is embedded inside the Go module at build time. No network download happens at runtime, and `go get` is the whole installation. On first use the embedded library is extracted to the user cache directory under a path that includes the SDK version and the target tuple. Subsequent process starts find the cached file and skip extraction. Target selection uses the Go runtime's own operating-system and architecture values, and the loaded library's version is checked against the SDK version before use. The default extraction path is: ```text /pit-go//-/ ``` Environment overrides: | Variable | Effect | | --- | --- | | `OPENPIT_RUNTIME_LIBRARY_PATH` | Load an explicit pre-extracted library file instead of the embedded copy. Extraction is skipped entirely. | | `OPENPIT_RUNTIME_CACHE_DIR` | Replace the user cache directory as the extraction root. The library then lands in `//-/`. | `OPENPIT_RUNTIME_LIBRARY_PATH` is what in-repository Go tests use to link against a freshly built runtime; see [Building From Source](Building-From-Source.md). `openpit.RuntimeLibraryPath()` returns the path of the library the process loaded, the override or the extracted copy, so a host can check an operator- supplied path against what actually runs. The module uses cgo, so a C toolchain must be available when your project is built. ## Python The Python package ships the runtime inside the wheel as a compiled extension module. Installing the package from the index is the whole installation: there is nothing to extract, no cache directory, and no environment variable to set. A source build from a checkout produces the same extension in place. ## JavaScript and TypeScript The JavaScript package needs no native library at all. The engine is compiled to WebAssembly and shipped inside the package in two platform builds behind one import. Both instantiate the WebAssembly module synchronously at load, so there is no `await` in the common path: - **Node** reads the sibling `.wasm` file from disk. Smallest footprint and fastest cold start. - **Browser and edge** use a base64-inlined WebAssembly module. No `fetch`, no `fs`, and no separately hosted asset, so any CDN works with zero configuration. The package ships ESM and CommonJS builds for Node `>=18` and for browser/bundler targets. Every environment resolves the root import or any subpath to the matching entry and module format: | Environment | Resolves to | WebAssembly | | --- | --- | --- | | Node ESM (`>=18`) | `node/.js` | from disk | | Node CommonJS (`>=18`) | `node/.cjs` | from disk | | Bundlers (Vite, webpack, Rollup, esbuild) | `browser/.{js,cjs}` | inlined | | Browsers via CDN (esm.sh, jsDelivr, unpkg) | `browser/.js` | inlined | | Deno (`npm:` specifier or esm.sh) | `node` / `browser` ESM entry | disk / inlined | | Bun | `node/.{js,cjs}` | from disk | | Cloudflare Workers and other edge runtimes | `browser/.{js,cjs}` | inlined | `` is `index` for the root import, or the subpath name for a subpath import (for example `param`, `marketdata`, or `pretrade/policies`). The inlined browser build needs no asset-loader configuration and makes no network request at import, so CDN and Workers usage is zero-config. ## C++ The C++ package is header-only, so the runtime is a separate library resolved when CMake configures the project. `find_package(OpenPit CONFIG REQUIRED)` exposes it as an imported target and tries three sources in order: 1. `OPENPIT_RUNTIME_LIBRARY` - absolute path to a prebuilt runtime library file. 2. `OPENPIT_RUNTIME_DIR` - a directory holding the host library under its platform-default name. 3. Download the matching release asset from GitHub and verify its SHA-256 sidecar. The first two are how a checkout build and an air-gapped build point the package at a library that already exists locally. The third is the default for a consumer that just declares the dependency. `OPENPIT_RUNTIME_VERSION` selects the runtime release version without the `v` prefix, for example `0.8.3`; it defaults to the C++ package version. `OPENPIT_RUNTIME_REPO` selects the GitHub `owner/repo` that hosts the release assets and defaults to `openpitkit/pit`. Set these CMake cache variables before `find_package` or `FetchContent_MakeAvailable` to use a matching release from a fork or internal mirror. The runtime library must match the SDK headers. On Windows the package resolves both the runtime DLL and the matching MSVC import library; `OPENPIT_RUNTIME_IMPORT_LIBRARY` pairs the import library with an explicitly supplied `OPENPIT_RUNTIME_LIBRARY`. If your application needs the DLL next to the executable at run time, ask the package to copy it: ```cmake openpit_copy_runtime_dll(your_target) ``` ## Rust and C The Rust crate is compiled from source by Cargo like any other dependency, so there is no separate runtime artifact to deliver. The C interface is the same native library the other bindings load, consumed directly through its generated header; the integrator chooses how to ship and link it. ## Related Pages - [Getting Started](Getting-Started.md): Install a released SDK in each language - [Building From Source](Building-From-Source.md): Build the runtime from a checkout and point an SDK at it - [Threading Contract](Threading-Contract.md): What the loaded runtime guarantees per call and per handle