plugin-candy

Placement	compiled-in (in-process)
Source	github.com/opencharly/plugin-candy/candy/plugin-candy
Version	2026.181.0001
Candy	plugin-candy

This plugin is listed in charly/charly.yml’s compiled_plugins:, so its providers are compiled into the charly binary and register in-process.

Providers

The reserved words this plugin serves:

• candy — command class

What it does

COMPILED-IN charly COMMAND-class plugin (command:candy) OWNING the entire charly candy CLI — the TOP-LEVEL candy-manifest authoring surface (set / add-rpm / add-deb / add-pac / add-aur). The plugin owns the ENTIRE logic: the subcommand grammar AND the comment-preserving yaml.Node mutation of candy//charly.yml (candySet / appendCandyPackages / candyBodyNode / ensureMappingChild — all in the plugin, none in core). There is NO core candy logic and NO HostBuild seam — a plugin editing yaml owns that itself. (This is NOT charly new candy — a different command, a child of charly new, that stays a builtin.)

The ONLY shared pieces are the GENERIC yaml utilities kit.SetByDotPath + kit.MappingChild (sdk/kit/yaml.go), which ALSO back charly box set + charly box scaffold — ONE copy, no duplication (R3). Nothing candy-specific crosses between core and the plugin.

Because the logic is self-contained — no reverse channel needed, the yaml mutation is host-local file work — charly candy works IDENTICALLY compiled-in OR out-of-process, like migrate. Listed in charly.yml compiled_plugins, it registers in-proc and the host dispatches it through dispatchInProcCommand → Invoke(OpRun) → runCandyCLI (which just runs directly — no executor, no HostBuild). The out-of-process placement fork/execs the module (cmd/serve → CliMain) running the SAME runCandyCLI; NewMeta advertises command:candy so the compiled-in registry path resolves it.

The R10 witness is the disposable check-commands-local bed: charly candy --help exits 0, proving the command tree resolves and dispatches end-to-end.

Parameter schema

The CUE schema below is the authoritative grammar for this plugin’s input. It is the same single source that generates the plugin’s Go parameter types and answers the runtime Describe RPC, so this page cannot disagree with either.

schema/candy.cue

// plugin-candy's OWN self-contained CUE schema — the SINGLE SOURCE for this plugin's
// served declaration surface (there is no schema-less plugin: every plugin ships a
// non-empty schema over Describe).
//
// SELF-CONTAINED and PACKAGE-LESS: it references no base def and carries no package
// clause, so it compiles STANDALONE — the property the SDK's serve-side compile needs
// and the property that lets the host splice `base ++ plugin` at the load gate
// (registerPluginUnitSchema); a self-contained schema that will not splice is a LOUD
// load failure.
//
// NO GO CONSUMER: the plugin declares no typed `plugin_input` (its authored input is
// its pass-through CLI grammar), so this schema generates NO `params` package and has
// NO `cue exp gengotypes` artifact — it is the SERVED documentation/config surface,
// not a code-generation source.
//
// It DOCUMENTS the `command:candy` surface: the `set` word plus the `add-<fmt>` words the dispatch serves (a manual mirror of the dispatch's distro-format list).
#CandyPlugin: {
  // The top-level command word this plugin serves.
  command: "candy"

  // The subcommands: `set` (dot-path mutation) + one `add-<fmt>` per
  // distro-format section. This is a MANUAL mirror of the dispatch's
  // distro-format list (`sectionDistroPath`); CUE cannot derive it at build time.
  subcommands: ["set", "add-rpm", "add-deb", "add-pac", "add-aur", "add-apk"]

  // What the plugin does, in one line (the public-docs surface).
  contract: string & !=""
}

---

See also the candy reference for this candy’s install surface.