Typed distributed plugin registration
1.3k
Stars
56
Forks
6
Open issues
14
Contributors
AI Analysis
Inventory provides typed distributed plugin registration for Rust applications, enabling plugins to be registered from any source file without maintaining a central registry. It is purpose-built for large-scale development where decentralized plugin registration avoids merge conflicts, particularly suited for command-line libraries, modular applications, and systems similar to Google's gflags pattern. This library is specialized for Rust systems developers and frameworks requiring plugin arch...
Inferred from signals mentioned in the README (tests, CI, type safety) — not a review of the actual code.
AI's overall editorial judgment — not an average of the bars above, can weigh other factors too.
Compile-time plugin registry for Rust: solves distributed registration without central coordination
Inventory is a Rust crate that enables compile-time, type-safe plugin registration across multiple source files without requiring a central registry file. Plugins are collected via macros at link time and made available via iterators. Built by dtolnay, a high-signal Rust ecosystem contributor. Addresses a real pattern in large-scale codebases (borrowed from gflags philosophy) but adoption appears limited to specialized use cases. No mainstream adoption evidence found.
Created December 2018 by David Tolnay. Emerged from the pattern used by Google's gflags library, where distributed flag registration avoids merge conflicts in large teams. Represents a specific solution to life-before-main plugin initialization in Rust, positioned as an alternative to the linkme crate for different use case priorities.
Steady but modest: 1,315 stars over ~7.5 years suggests stable, niche utility rather than rapid growth. Last push 2026-06-24 (8 days before evaluation date) indicates active maintenance. Appears to have found its audience among infrastructure developers familiar with gflags-style patterns, with growth plateauing around 150–200 stars annually based on trajectory. One star in last 7 days reflects typical engagement for a mature, specialized tool.
Adoption not verified. No case studies, known users, or production deployment mentions in README. Author's high reputation (dtolnay) and crate metadata suggest some internal or indirect adoption, but explicit evidence is absent. Crates.io download metrics not provided in available metadata.
Likely uses runtime initialization functions (constructor attributes) similar to ctor crate for platform-specific plugin registration. README indicates support for Linux, macOS, iOS, FreeBSD, Android, Windows, WebAssembly, and others via platform-specific life-before-main mechanisms. Plugins are collected at link time, not runtime, making them static. Intentionally contrasts with linkme, which does not involve life-before-main initialization.
Not documented in README. CI workflow badge present, but actual test strategy and coverage metrics are not disclosed.
Recent push (2026-06-24, 8 days ago) and CI passing. Repository has steady, low-frequency maintenance pattern consistent with a mature, stable crate. No evidence of abandonment. Appears actively maintained but not undergoing major feature development.
ADOPT IF: You are building a large Rust project with geographically distributed teams/modules that need to register flags, handlers, or config entries without a central coordination point, AND you are comfortable with life-before-main semantics and platform-specific initialization behavior. AVOID IF: You require dynamic plugin loading, need runtime-discovered plugins from external libraries not linked at compile time, or are building a general-purpose plugin framework (use custom solutions or bevy-style ECS). MONITOR IF: You are evaluating plugin systems for a mid-sized infrastructure project and want to understand whether distributed registration will reduce merge conflicts more than the added complexity costs; consider prototyping with a smaller scope first.
Independent dimensions
Mainstream potential
3/10
Technical importance
6/10
Adoption evidence
1/10
- Life-before-main initialization semantics are non-obvious and may surprise developers unfamiliar with constructor attributes; debugging plugin registration failures is non-trivial.
- Platform-specific behavior: plugins may silently fail to register on unsupported platforms without clear error messages.
- No documented way to introspect or debug which plugins were registered or why registration failed; iteration order is unspecified.
- Adoption is too narrow and unverified to assume stable community support or third-party ecosystem; future maintenance depends on dtolnay's continued involvement.
- Link-time collection means plugin registration is static; dynamic plugin systems (loading .so/.dll at runtime) require alternative patterns.
Likely to remain a stable, low-growth niche tool used by infrastructure projects that explicitly adopt the gflags registration philosophy. Unlikely to broaden to general-purpose plugin systems or mainstream adoption. Will continue to be maintained at current pace as long as dtolnay remains active in Rust ecosystem.
Newsletter
Get analyses like this every Monday
Free weekly digest of the most interesting open-source discoveries.
Languages
Information
- Language
- Rust
- License
- Apache-2.0
- Last updated
- 2w ago
- Created
- 92mo ago
- Analyzed with
- anthropic/claude-haiku-4-5
Stars over time
Contributors over time
Top 100 contributors only — repos with more will plateau at 100.
Open issues
Does this library have expectations of soundness when it comes to rust dependencies being loaded in dylibs?
linker failure when using ASAN in a project with inventory on macOS
Rust version 1.90.0 has issues with linking inventory crates on Windows MSVC
Behavior in multi-crate projects
Figure out and document how registration works when plugins are loaded dynamically by dlopen
Open pull requests
Top contributors
Recent releases
Similar repos
dtolnay/case-studies
A specialized educational repository that dissects tricky Rust code patterns...
| Repository | Stars | Week Δ | Language | Score | Updated |
|---|---|---|---|---|---|
|
|
1.3k | +3 | Rust | 8/10 | 2w ago |
|
|
1.6k | — | Rust | 8/10 | 1w ago |
|
|
2k | — | Rust | 8/10 | 2w ago |
|
|
3.3k | — | Rust | 9/10 | 1d ago |
|
|
1.5k | — | Rust | 8/10 | 2w ago |
|
|
7.3k | — | Rust | 8/10 | 4w ago |
Alternative plugin registration crate by same author. Differs philosophically: linkme avoids life-before-main, likely better for dynamic plugin loading; inventory uses constructor-based registration, better for static, compile-time collection.
Lower-level constructor attribute support. Inventory builds on similar machinery but provides higher-level plugin registry semantics; ctor is more general-purpose.
Game engines and ECS frameworks often implement plugin systems independently. Inventory provides a narrower, more explicit pattern suited to flag/config registration rather than general-purpose plugin architecture.
Many Rust projects build custom plugin registration via hand-written macros and static initialization. Inventory provides a reusable abstraction.