Module provisioning 

Pluggable tool provisioning: given a declared ToolSpec, resolve a runnable executable path via, in order: Adopt (already on PATH), native package manager (apt/dnf/brew/winget/choco, whichever matches the current OS and is available), git install (clone the tool’s own repo and build it from source — the same pattern prometheus-skill-system/prometheus-entity-management already use as submodules), and prebuilt binary (download + extract a release archive for the detected OS/arch).

This module is deliberately separate from super::process_supervisor, which solves a different problem: detecting and reusing an already-running TCP-listening service. The dependencies this module provisions (MCP stdio server commands, skill-compilation toolchains) are executables you run fresh each time, not services you connect to — there’s nothing to “adopt” in the TCP sense, only “does this binary exist yet.”

Strategies 2–4 default to detection-only unless ProvisionOptions::allow_install is set — installing system packages, cloning+building third-party source, or downloading and extracting an archive are all real, host-modifying actions this module will not take silently.

Structs

GitInstallSpec

Git-install strategy: clone url into a cache dir and run build_cmd (argv, first element is the program) inside it. binary_relpath is where the resulting executable ends up relative to the clone root.

PerOsPackageName

Per-OS package name for the native-package-manager strategy. None for an OS/manager combination means “don’t attempt this manager for this tool.”

PrebuiltSpec

Prebuilt-binary strategy: a URL template with {os}/{arch} placeholders pointing at a downloadable archive, plus the path of the binary inside it once extracted.

ProvisionOptions

Controls whether strategies 2–4 may actually modify the host.

ProvisionOutcome

Result of a successful ToolProvisioner::resolve call.

ToolProvisioner

ToolSpec

Declares how to obtain one tool.

Enums

Strategy

Which strategy actually resolved a ToolSpec.

Functions

is_on_path

Cheap, allocation-light check for whether name is already resolvable — either an existing absolute/relative path, or found on PATH. Intended for call sites (like mcp/registry.rs’s stdio spawn path) that want to preserve their fast path and only invoke ToolProvisioner::resolve when this returns false.

known_tool_spec

Curated ToolSpec for tool names this codebase already documents an install path for (see Cargo.toml’s comment above the kreuzberg dependency and docs/DEPENDENCY_MANAGEMENT.md). Returns a bare, strategy-less spec (Adopt-only) for anything not curated — this deliberately does not invent installation strategies for arbitrary, uncurated tool names (e.g. npx, uvx, or a user’s own MCP command).

skill_toolchain_specs

ToolSpecs for the 5 skill-compilation toolchains the Dockerfile (#13 in prometheus-package-integration) bakes into the runtime image — Rust, Node, Python, Go, wasmtime. Package/URL choices here deliberately mirror the Dockerfile’s own install methods where practical, so the two don’t drift (Go and wasmtime both use the same prebuilt-release pattern the Dockerfile does; Rust/Node/Python use each OS’s default package manager rather than the Dockerfile’s more specific rustup/nodesource scripts, which don’t map cleanly onto this module’s 4-strategy shape).