Skip to content

Runtime Delivery

Jump to bottom
Eugene Palchukovsky edited this page Aug 1, 2026 · 1 revision

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:

<user-cache>/pit-go/<version>/<goos>-<goarch>/

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 <override>/<version>/<goos>-<goarch>/.

OPENPIT_RUNTIME_LIBRARY_PATH is what in-repository Go tests use to link against a freshly built runtime; see Building From Source.

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/<entry>.js from disk
Node CommonJS (>=18) node/<entry>.cjs from disk
Bundlers (Vite, webpack, Rollup, esbuild) browser/<entry>.{js,cjs} inlined
Browsers via CDN (esm.sh, jsDelivr, unpkg) browser/<entry>.js inlined
Deno (npm: specifier or esm.sh) node / browser ESM entry disk / inlined
Bun node/<entry>.{js,cjs} from disk
Cloudflare Workers and other edge runtimes browser/<entry>.{js,cjs} inlined

<entry> 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.

The release version and the repository hosting the releases are themselves CMake variables, so a fork or an internal mirror can serve the asset instead of the public one.

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:

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

Clone this wiki locally