Skip to main content
Version: 0.5.x

Introduction​

services.Manifest() returns the current plugin-scoped manifest resource reading service. Paths are always relative to the manifest/ directory — for example, to read manifest/profile.yaml, pass profile.yaml.

Dynamic plugins use the same semantics but must declare the manifest service and allowed paths in plugin.yaml.

Capability Phase: Runtime

Supported Plugin Types: Source plugins, Dynamic plugins

Capability Design​

Resource Binding Mechanism​

Resources are bound to the current plugin: for source plugins they come from the embedded filesystem, for dynamic plugins from the published artifact or host-bound artifact resources. Paths must be canonical, using forward slashes, and escaping the current plugin's manifest/ root through relative paths is prohibited.

Resource Types​

Path ExampleDescription
profile.yamlPlugin profile or display metadata
config/config.example.yamlConfig template, not used for runtime default reads
config/config.yamlOne of the plugin's default config sources
i18n/zh-CN/plugin.jsonChinese language resources
sql/install.sqlInstall script raw resource

Read-Only Raw Resource Semantics​

Reading resources does not mean executing SQL, registering language packs, or applying configuration. Configuration reading has dedicated capabilities. Runtime config values use Plugins().Config() or dynamic config.get; do not read config/config.yaml directly to bypass priority.

Interface Definitions​

Source Plugin Interface​

MethodDescription
GetReads the raw byte content at a specified path
GetManyBatch-reads raw resource content for a set of specified paths
ListReturns resource metadata list under a specified prefix
ExistsChecks whether a resource at a specified path exists
ScanScans a YAML resource or nested key within it into the target struct

Dynamic Plugin Interface​

Dynamic MethodDynamic SDK MethodDescription
getManifest().Get, Manifest().GetMany, Manifest().List, Manifest().Exists, Manifest().ScanReads raw resources under authorized paths

Capability Usage​

Source Plugin Usage​

Source plugins read resources shipped with the plugin through services.Manifest():

// Read plugin profile
content, err := services.Manifest().Get(ctx, "profile.yaml")

// Batch-read multiple resources
result, err := services.Manifest().GetMany(ctx, manifestcap.GetManyInput{
    Paths: []string{"profile.yaml", "config/config.yaml"},
})

// List resource metadata
listResult, err := services.Manifest().List(ctx, manifestcap.ListInput{
    Prefix: "i18n/",
    Limit:  50,
})

// Check if a resource exists
exists, err := services.Manifest().Exists(ctx, "i18n/zh-CN/plugin.json")

// Scan YAML resource into struct
var config PluginConfig
err := services.Manifest().Scan(ctx, "config/config.yaml", "", &config)

Dynamic Plugin Usage​

Dynamic plugins declare the manifest service and authorized paths in plugin.yaml:

hostServices:
  - service: manifest
    methods:
      - get
    resources:
      paths:
        - profile.yaml
        - i18n/zh-CN/plugin.json

When manifest omits methods, it defaults to get. resources.paths must be paths relative to manifest/, not manifest/profile.yaml. Usage on the dynamic plugin side:

// Read plugin profile
content, err := pluginbridge.Default().Manifest().Get(ctx, "profile.yaml")

// Check if a resource exists
exists, err := pluginbridge.Default().Manifest().Exists(ctx, "i18n/zh-CN/plugin.json")

Design Constraints​

  • Read-only raw resources. Reading resources does not mean executing SQL, registering language packs, or applying configuration.
  • Configuration reading has dedicated capabilities. Runtime config values use Plugins().Config() or dynamic config.get; do not read config/config.yaml directly to bypass priority.
  • Resources are bound to the current plugin. For source plugins they come from the embedded filesystem, for dynamic plugins from the published artifact or host-bound artifact resources.
  • Paths must be canonical. Use forward slashes; escaping the current plugin's manifest/ root through relative paths is prohibited.