plugin-candy

Placement	compiled-in (in-process)
Source	github.com/opencharly/charly/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.

---

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