Skip to content

feat: adopt plugin directory/bundle convention for runtime manifest discovery #254

@staging-devin-ai-integration

Description

@staging-devin-ai-integration

Summary

Plugins currently consist of a single .so file placed in .plugins/native/. The plugin manifest (plugin.yml) lives separately in the source tree under plugins/native/<id>/ and is only used at build/packaging time. This creates a disconnect: at runtime, the server has no way to discover a plugin's declared asset types, models, or other metadata without a separate manifest file being present alongside the .so.

Problem

  • A bare .so file in .plugins/native/ has no associated manifest at runtime.
  • The plugin asset registration system (PR feat: plugin-driven asset registration system #253) requires plugin.yml to be read at load time to discover asset types. Currently this is handled during the initial spawn_load_existing scan and marketplace install, but local development plugins placed directly as .so files don't have their manifests available.
  • As plugins evolve to potentially include custom UI, models, and other resources, a single-file convention becomes increasingly limiting.

Proposal

Adopt a plugin directory convention where each plugin is a directory containing its artifacts:

.plugins/native/slint/
├── plugin.so          # compiled plugin binary
├── plugin.yml         # manifest (assets, models, metadata)
└── ui/                # (future) custom UI components

This aligns with the marketplace bundle format (which is already a tar.gz containing both files) and provides a natural extension point for future plugin capabilities.

Migration path

  1. Update the plugin loader to scan directories under .plugins/native/<id>/ instead of individual .so files.
  2. Fall back to bare .so files for backward compatibility during a transition period.
  3. Update the marketplace installer to extract bundles into the directory structure (it may already do this).
  4. Update justfile build targets to output plugins into the directory structure.

Alternatives considered

  • Embed manifest in .so via C ABI: Plugin exposes a plugin_manifest() symbol. Single artifact, but requires ABI extension and doesn't work for WASM plugins.
  • Hybrid: .so embeds minimal metadata, plugin.yml extends. More complex merge semantics.

Context

Discussion from PR #253 (plugin-driven asset registration). The directory convention was identified as the natural evolution given that plugins will eventually become bundles that could ship custom UI.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions