m11-ecosystem
actionbook/rust-skills
Navigate Rust crate selection, dependency management, and ecosystem integration decisions.
What is m11-ecosystem?
Use this skill when choosing which crates to add, managing Cargo dependencies, resolving import errors (E0425, E0433, E0603), configuring features, or integrating language interop (C/C++, Python, WebAssembly). It provides decision frameworks for evaluating crate maintenance, scope, and integration patterns before adding dependencies.
- Evaluate crate maintenance status, API stability, and community activity before integration
- Resolve common dependency errors (E0433, E0603) and version conflicts
- Select appropriate crates for serialization, async, HTTP, database, CLI, and logging needs
- Configure Cargo features and workspaces to manage optional functionality and multi-crate projects
- Guide language interop decisions for C/C++ (bindgen, cbindgen), Python (PyO3), Node.js (napi-rs), and WebAssembly (wasm-bindgen)
How to install m11-ecosystem
npx skills add https://github.com/actionbook/rust-skills --skill m11-ecosystemHow to use m11-ecosystem
- 1.Identify your integration need (serialization, async, HTTP, database, etc.) and check the decision table
- 2.Evaluate the candidate crate using the maintenance criteria: recent commits, active issues, documentation quality, semantic versioning
- 3.Check if feature flags can reduce bloat or if the full crate is necessary
- 4.Review the crate's API design (trait-based vs concrete, sync vs async) against your bounds and constraints
- 5.Add to Cargo.toml with a specific version, enable required features, and test for conflicts
Use cases
- Deciding between tokio vs async-std for async runtime, or axum vs actix-web for HTTP servers
- Resolving 'cannot find crate' errors by checking Cargo.toml and feature flag configuration
- Evaluating whether to use serde, sqlx, or diesel based on project constraints
- Setting up FFI bindings to external C libraries or creating Python extensions
- Managing multi-crate workspaces and preventing duplicate type conflicts across versions
- Rust developers integrating third-party crates or building ecosystem-dependent features
- Teams evaluating crate maintenance and supply-chain risk before adoption
- Developers working with language interop (C, Python, WebAssembly, Node.js)
- Library authors deciding what to expose via feature flags
m11-ecosystem FAQ
Check that the crate is listed in [dependencies] in Cargo.toml with the correct name and version. If using a feature-gated item, ensure the feature is enabled in the features list.
Use feature flags when a crate offers optional functionality you may not need; this reduces compile time and binary size. Add the full dependency only if you use most of its functionality.
Evaluate maintenance status, community adoption, documentation, and API fit. Tokio is the de facto standard for async Rust; choose alternatives only if they better match your constraints.
Use bindgen to auto-generate Rust bindings from C headers, or cbindgen to export Rust code as C headers. For complex FFI, wrap unsafe blocks carefully and document safety invariants.
Use a workspace [dependencies] section to unify versions across crates, or pin specific versions in Cargo.toml. Run cargo update to resolve conflicts and check for duplicate types from different versions.
Full instructions (SKILL.md)
Source of truth, from actionbook/rust-skills.
name: m11-ecosystem description: "Use when integrating crates or ecosystem questions. Keywords: E0425, E0433, E0603, crate, cargo, dependency, feature flag, workspace, which crate to use, using external C libraries, creating Python extensions, PyO3, wasm, WebAssembly, bindgen, cbindgen, napi-rs, cannot find, private, crate recommendation, best crate for, Cargo.toml, features, crate 推荐, 依赖管理, 特性标志, 工作空间, Python 绑定" user-invocable: false
Current Dependencies (Auto-Injected)
!grep -A 100 '^\[dependencies\]' Cargo.toml 2>/dev/null | head -30 || echo "No Cargo.toml found"
Ecosystem Integration
Layer 2: Design Choices
Core Question
What's the right crate for this job, and how should it integrate?
Before adding dependencies:
- Is there a standard solution?
- What's the maintenance status?
- What's the API stability?
Integration Decision → Implementation
| Need | Choice | Crates |
|---|---|---|
| Serialization | Derive-based | serde, serde_json |
| Async runtime | tokio or async-std | tokio (most popular) |
| HTTP client | Ergonomic | reqwest |
| HTTP server | Modern | axum, actix-web |
| Database | SQL or ORM | sqlx, diesel |
| CLI parsing | Derive-based | clap |
| Error handling | App vs lib | anyhow, thiserror |
| Logging | Facade | tracing, log |
Thinking Prompt
Before adding a dependency:
-
Is it well-maintained?
- Recent commits?
- Active issue response?
- Breaking changes frequency?
-
What's the scope?
- Do you need the full crate or just a feature?
- Can feature flags reduce bloat?
-
How does it integrate?
- Trait-based or concrete types?
- Sync or async?
- What bounds does it require?
Trace Up ↑
To domain constraints (Layer 3):
"Which HTTP framework should I use?"
↑ Ask: What are the performance requirements?
↑ Check: domain-web (latency, throughput needs)
↑ Check: Team expertise (familiarity with framework)
| Question | Trace To | Ask |
|---|---|---|
| Framework choice | domain-* | What constraints matter? |
| Library vs build | domain-* | What's the deployment model? |
| API design | domain-* | Who are the consumers? |
Trace Down ↓
To implementation (Layer 1):
"Integrate external crate"
↓ m04-zero-cost: Trait bounds and generics
↓ m06-error-handling: Error type compatibility
"FFI integration"
↓ unsafe-checker: Safety requirements
↓ m12-lifecycle: Resource cleanup
Quick Reference
Language Interop
| Integration | Crate/Tool | Use Case |
|---|---|---|
| C/C++ → Rust | bindgen | Auto-generate bindings |
| Rust → C | cbindgen | Export C headers |
| Python ↔ Rust | pyo3 | Python extensions |
| Node.js ↔ Rust | napi-rs | Node addons |
| WebAssembly | wasm-bindgen | Browser/WASI |
Cargo Features
| Feature | Purpose |
|---|---|
[features] | Optional functionality |
default = [...] | Default features |
feature = "serde" | Conditional deps |
[workspace] | Multi-crate projects |
Error Code Reference
| Error | Cause | Fix |
|---|---|---|
| E0433 | Can't find crate | Add to Cargo.toml |
| E0603 | Private item | Check crate docs |
| Feature not enabled | Optional feature | Enable in features |
| Version conflict | Incompatible deps | cargo update or pin |
| Duplicate types | Different crate versions | Unify in workspace |
Crate Selection Criteria
| Criterion | Good Sign | Warning Sign |
|---|---|---|
| Maintenance | Recent commits | Years inactive |
| Community | Active issues/PRs | No response |
| Documentation | Examples, API docs | Minimal docs |
| Stability | Semantic versioning | Frequent breaking |
| Dependencies | Minimal, well-known | Heavy, obscure |
Anti-Patterns
| Anti-Pattern | Why Bad | Better |
|---|---|---|
extern crate | Outdated (2018+) | Just use |
#[macro_use] | Global pollution | Explicit import |
Wildcard deps * | Unpredictable | Specific versions |
| Too many deps | Supply chain risk | Evaluate necessity |
| Vendoring everything | Maintenance burden | Trust crates.io |
Related Skills
| When | See |
|---|---|
| Error type design | m06-error-handling |
| Trait integration | m04-zero-cost |
| FFI safety | unsafe-checker |
| Resource management | m12-lifecycle |
Related skills
More from actionbook/rust-skills and the wider catalog.
m12-lifecycle
Design resource creation, usage, and cleanup patterns using RAII, Drop, and lifecycle strategies.
m13-domain-error
Design domain error handling with categorization, recovery strategies, and resilience patterns.
m14-mental-model
Mental models and analogies for understanding Rust ownership, borrowing, and core concepts.
m15-anti-pattern
Identify and refactor Rust code anti-patterns during review.
meta-cognition-parallel
Three-layer parallel meta-cognition analysis for Rust questions—language mechanics, design choices, and domain constraints.
rust-call-graph
Visualize Rust function call graphs and trace caller/callee relationships using LSP.