Conversation
This is the core of the registry-centric plugin distribution RFD. It replaces the ad-hoc plugin-source machinery with an in-process package-manager (PM) seam and rebuilds plugin and skill resolution on top of it. PM layer (src/pm/): - PackageId (pm, name, version), the PackageManager trait (active_plugins/load_plugin/list_deps/search/fetch, plus refresh — pull a registry's content, a no-op for local sources — and registry_source), PluginInfo, FetchedPackage, and PmRegistry — one flat set of PmInstances dispatched by id.pm, each carrying a `trusted` marker (registries + workspace are trust roots; the cargo transport over dependencies is not). - CargoPm transport (pm/cargo/): holds an Arc<WorkspaceDeps> and drives the lazy, disk-cached `cargo metadata` resolution; builds crate-embedded plugins; searches crates.io. - PathPm / GitPm + layout: registry instances over a local directory or a git repository. A GitPm delegates its reads to an inner PathPm over the cache dir and owns `refresh` (pulling the repo); config builds the registry instances directly (git -> GitPm, path -> PathPm). - WorkspaceDeps and SymposiumDirs move out of symposium-sdk into the main crate (pm/cargo/workspace.rs, dirs.rs). Plugin loading (plugins.rs): - ParsedPlugin carries a canonical PackageId as its identity and no longer a manifest/base path; every source path is resolved to absolute at load. - Registry loading goes through the trusted PM instances; crate manifests load leniently and merge; a bare SKILL.md and a bare crate each become a default plugin. A registry plugin with no dependency gate is dormant until `use`d. - active_plugins — the worklist fixed-point that resolves the active plugin set (registry plugins plus crate-sourced ones reached through [[plugins]] chained references and dependency enablement) — lives here, since it's consumed by every facet (skills, MCP, hooks, subcommands), not just skills. Skill resolution (skills.rs): collect_skills walks the active set; skill identity is the hash of the on-disk SKILL.md path. Discovery + enablement (discovery.rs, config.rs): the [plugins] enablement axis, dependency discovery over the untrusted cargo transport, and the sync-time consent prompt. Predicates (predicate.rs): one unified Predicate enum + PredicateContext. Consumers (hook, sync, subcommand_dispatch, help_render, crate_command, crate_metadata, report, init, workspace_state, cli, bin) are migrated to the new APIs. Fixtures are updated to the current manifest schema. The user-facing enablement commands (use/search/status) and the design docs follow in separate commits.
The user-facing surface over the [plugins] enablement axis and the package-manager search, layered on the PM core: - `cargo agents use <name>` / `--remove` / `--global`: records a durable enablement (workspace-scoped by default), resolving the name against a workspace dependency or a crates.io search first, then re-syncs. - `cargo agents search <query>`: unions plugin-name matches from the loaded registry with PmRegistry::search across every instance (crates.io included), grouped by origin. - `cargo agents status`: renders the enablement report — registry plugins (active / dormant), discovered dependency-embedded plugins by consent bucket, and used non-dependency crates. Wires the three subcommands into cli.rs / the binary's logging and help audience, and adds tests/enablement.rs plus the help snapshots that now list them.
…layer Rewrites the contributor docs to the shipped design: the package-manager seam (active_plugins/load_plugin, flat trust-marked PmRegistry), the worklist fixed-point over the PM set, absolute skill dirs and id-based plugin identity, dependency discovery and the enablement axis. Aligns the registry-centric-plugins RFD's predicate list and recommendations model with what shipped and records the remaining out-of-process / plugin-defined PM work.
Adds the cargo-agents use/search/status reference pages and updates the configuration, plugin-definition, plugin-source, predicates, depends-on, and crate-author guides for the [plugins] enablement axis and the package-manager-backed registries. Updates SUMMARY.md with the new pages.
jackh726
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Registry-centric plugin distribution (in-process core)
Implements the core of the registry-centric plugin distribution RFD:
a package-manager (PM) seam that plugins are discovered, fetched, and
activated through, with predicate-gated activation and dependency/user-driven
enablement.
Implemented
SYMPOSIUM.tomlmanifests,[defaults], unified predicates, chained[[plugins]]references, and dormancy (a gate-less registry plugin stays inactive untilused).PackageId (pm, name, version), aPackageManagertrait, and a flat, trust-markedPmRegistry. Three PMs: cargo (workspace deps + crates.io), path registries, and git registries.[plugins]consent axis (auto-enable/use/disable); the workspace and configured registries are trust roots, dependencies are not.use,search,status.Not yet (relative to the RFD)
PmRegistryis the seam for it).workspace-dependency()/used()/workspace-directory(); renamedworkspace()→workspace-member()andfile-exists→path_exists(depends-on(...)+useenablement cover those cases).Disclosure questions
AI disclosure.