# Plugin Registry: Ecosystem Survey
rsconstruct uses a hand-built plugin registry where processors self-register
at link time via `inventory::submit!`, declare their config schema, and are
instantiated from TOML config at runtime. This page documents the search for
existing Rust crates that could replace this machinery.
## What rsconstruct needs
The plugin system combines four responsibilities:
1. **Link-time self-registration** — each processor file submits a plugin
entry. No central list to maintain. Adding a processor = adding one file.
2. **Per-plugin TOML config** — each plugin declares known fields, required
fields, defaults, and a `create(toml::Value) -> Box<dyn Processor>`
factory. The framework deserializes the matching `[processor.NAME]`
section and passes it to the factory.
3. **Defaults and validation** — processor defaults, scan defaults, and
output-dir defaults are applied in layers before deserialization. Unknown
fields are rejected. Required fields are enforced.
4. **Name-to-factory mapping** — the registry maps processor names to their
plugin entries for creation, introspection (`processors list`), and
config display.
## Crates evaluated
### inventory / linkme
The foundation rsconstruct already uses. `inventory` provides link-time
collection of typed values into a global iterator. `linkme` does the same
via distributed slices. Neither has any config awareness — they solve (1)
only.
- **Verdict:** already in use; does its job well.
### spring-rs
The closest match conceptually. A Spring Boot-style Rust framework that
combines `inventory`-based plugin registration with TOML config via
`#[derive(Configurable)]` and `#[config_prefix = "..."]` attributes. Each
plugin declares its config struct with the derive macro, and the framework
auto-deserializes the matching TOML section.
However, spring-rs is a **full application framework** for web services
(integrates axum, sqlx, OpenTelemetry, etc.). Pulling it in for a build
tool would add a massive, opinionated dependency tree for ~50 lines of
glue code savings.
- **Verdict:** right pattern, wrong scope. Not suitable.
### config (crate)
Handles layered config loading from multiple sources (TOML, YAML, JSON,
env vars) with type-safe deserialization. No plugin registration awareness
at all — it's a config library, not a plugin framework.
- **Verdict:** solves config layering, not plugin registration.
### extism
A WebAssembly plugin runtime. Plugins are compiled to WASM and loaded at
runtime with sandboxing. Completely different problem — runtime-loaded
external plugins vs. compile-time self-registering internal plugins.
- **Verdict:** wrong problem domain.
### plugin-interfaces
Designed for chat-client applications with FFI and inter-plugin messaging.
Not relevant to build tools.
- **Verdict:** not applicable.
### toml-cfg
Provides compile-time config macros (`#[toml_cfg::toml_config]`) that
embed config values from a TOML file at build time. No runtime registry,
no plugin awareness.
- **Verdict:** compile-time only; not what we need.
## Conclusion
No existing crate provides the combination of link-time registration +
per-plugin TOML config deserialization + defaults/validation + name-to-factory
mapping. This is a genuine gap in the Rust ecosystem.
rsconstruct's manual approach (~50 lines of glue in `src/registries/processor.rs`
using `inventory::submit!` + serde + the `ProcessorPlugin` struct) is the
standard Rust pattern for this. It is well-understood, has no external
framework dependency, and is unlikely to be improved upon by a third-party
crate without bringing in unrelated complexity.
**Decision:** keep the current hand-built registry. Revisit if a focused
plugin-config crate emerges in the ecosystem.
*Survey conducted: April 2026.*