vox-plugin-host API Reference (generated)
vox-plugin-host
Section titled “vox-plugin-host”Crate: vox-plugin-host · Version: 0.6.0 · Target: Library (lib.rs)
Vox host-side plugin discovery, loading, and registry.
Crate Overview
Section titled “Crate Overview”Vox plugin host: discovery, loading, registry.
See: docs/src/architecture/plugin-system-redesign-2026.md
Spec §4.2(d): a plugin whose manifest version disagrees with the
running core’s own CARGO_PKG_VERSION must be refused before any
attempt to resolve or dlopen its dylib.
Workspace Dependencies
Section titled “Workspace Dependencies”| Dependency | Kind |
|---|---|
vox-plugin-api | Normal |
vox-plugin-types | Normal |
vox-secrets | Normal |
vox-telemetry | Normal |
vox-config | Development |
Public API Surface
Section titled “Public API Surface”Modules
Section titled “Modules”| Module | Description |
|---|---|
capability | — |
discover | — |
errors | — |
external_skills | — |
host_impl | — |
loader | — |
registry | — |
skill_author | — |
skill_bundle | — |
skill_manifest | — |
skill_parser | — |
skill_registry | — |
telemetry | — |
user_install | — |
Functions
Section titled “Functions”| Function | Description |
|---|---|
resolve_plugins_root | Resolve the plugin install root, respecting $VOX_PLUGINS_DIR if set. Falls back to the platform’s local data directory under vox/plugins. |
format_install_hint | Format the canonical multi-line install hint for a missing plugin. Always includes the catalog command (vox plugin install <id>). When the caller is running from a Vox workspace checkout that contains the plugin source under crates/vox-plugin-<id>/, also appends the local-path variant so contributors get a copy-pasteable command pointing at their own checkout (no GitHub fetch needed). Optionally appends a “Build with cargo:” line when the caller knows the plugin is enabled behind a cargo feature flag on a vox crate (e.g. vox-ml-cli’s gpu / mens-candle-cuda). Pass Some(cargo_hint) with the command body — cargo build -p vox-ml-cli --release --features .... |
workspace_local_plugin_source | Detect the in-tree source directory for a plugin id when running from a Vox workspace checkout. Used by load_code_plugin to make the “plugin not installed” error message actionable for contributors and by vox plugin install <id> (catalog path) to prefer the local checkout over fetching a release tarball. Walks up from CWD looking for a crates/vox-plugin-<id>/Plugin.toml. Returns Some(path-to-crate-dir) on the first hit, None otherwise. Honors VOX_WORKSPACE_ROOT as an explicit override. |
current_target_triple_key | Return the target-triple key used in [plugin.payload.artifacts] for the current build. The format is "<os>-<arch>" where os is "windows", "linux", or "macos" and arch is "x86_64" or "aarch64". This matches the keys emitted by the Plugin.toml generator and by vox plugin install. |
load_code_plugin_by_id | Convenience wrapper: discover the plugin install root, build the registry, and load a code plugin by id in a single call. For one-off dispatches from async contexts, wrap in tokio::task::spawn_blocking. |
load_code_plugin | Discover the given plugin in registry, resolve the dylib path for the current target triple, and load it via [Loader]. This is the preferred one-shot entry point for code-payload plugins. Callers can then call .plugin.as_ml_backend() (or the relevant extension point accessor) on the returned [LoadedCodePlugin]. |
cached_code_plugin | Cached singleton: load a code plugin once and reuse the handle process-wide. First call: discover + dlopen (tens of ms). Subsequent calls: O(1) HashMap lookup. The plugin is leaked for the process lifetime (Box::leak) — code plugins are designed to never unload while the host is running. Designed for plugins called repeatedly (browser, mesh, ml backends). |