Select named Plugin dependencies

Bind separate uses of the same Capability to exact provider Instances.

A sync Plugin can depend on two Document Stores: source reads and destination writes. Both use the same Capability, with distinct stable requirement IDs local to the consumer Contract. They may select different Instances or explicitly use one Instance for both roles. Renaming a private field does not migrate a saved public requirement identity.

Declare and consume dependencies

This excerpt comes from the document-sync example. DOCUMENT_STORE_CONTRACT is the project’s generated Contract:

const source = dependency({ id: "source", contract: DOCUMENT_STORE_CONTRACT });
const destination = dependency({ id: "destination", contract: DOCUMENT_STORE_CONTRACT });

Declare dependencies: { source, destination } in definePlugin and receive its generated clients in create({ dependencies }). Rust generated clients can use dependencies.requirement("source") for the corresponding dependency view. The Host authorizes candidates and the Resolver records exact choices in the immutable Plan. Plugin code does not discover providers or choose accounts at call time.

Select providers for an existing App

These commands assume the Host permits both requirements of company.copy/default to select the configured Store Instances. Host-fixed bindings and Host-ordered many requirements cannot be overridden this way.

lenso plugins bind company.copy source company.store --provider-instance source --root ./my-app
lenso plugins bind company.copy destination company.store --provider-instance destination --root ./my-app
lenso app check --root ./my-app
lenso app show --root ./my-app --json

For an optional dependency, save explicit absence with lenso plugins bind company.copy cache --absent --root ./my-app. Adding a compatible provider preserves existing choices. A missing, disabled, incompatible, or forbidden selected provider fails validation without choosing a different account automatically.

Resolve several choices or migrate names together

When both dependencies are ambiguous, submit a complete choice file to avoid an invalid intermediate state:

{
  "schema_version": 1,
  "choices": [
    {
      "consumer": { "plugin_id": "company.copy", "instance_key": "default" },
      "requirement_id": "source",
      "provider": { "plugin_id": "company.store", "instance_key": "source" }
    },
    {
      "consumer": { "plugin_id": "company.copy", "instance_key": "default" },
      "requirement_id": "destination",
      "provider": { "plugin_id": "company.store", "instance_key": "destination" }
    }
  ]
}

lenso plugins bind --file dependency-choices.json --preview --root ./my-app
lenso plugins bind --file dependency-choices.json --root ./my-app

The file is the complete choice set and replaces stale saved requirement IDs; positional bind changes one key. Preview reports provider transitions and validation problems without publishing. Choices live in plugins/.dependencies.json. Startup and inspection are read-only; configuration operations own explicit migration and transaction recovery. Publishing configuration and replacing the running Generation are separate steps; inspect runtime state through the Host.

Complete Host selection rules.