plugin-settings
| Placement | compiled-in (in-process) |
| Source | github.com/opencharly/charly/candy/plugin-settings |
| Version | 2026.181.0001 |
| Candy | plugin-settings |
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
Section titled “Providers”The reserved words this plugin serves:
settings— command class
What it does
Section titled “What it does”COMPILED-IN charly COMMAND-class plugin that OWNS the externalized charly settings
CLI — the runtime-configuration surface. The plugin owns the command end to end: the
get/set/list/reset/path subcommand grammar (command.go runSettingsCLI) and the output
formatting. No plugin-specific command LOGIC is left in core.
This plugin OWNS its entire config subsystem — read/write the runtime config file ~/.config/charly/config.yml (GetConfigValue / SetConfigValue / ListConfigValues / ResetConfigValue / RuntimeConfigPath) + the runtime-engine resolution — directly in config.go (ported from charly/runtime_config_values.go + charly/host_build_settings.go), as almost-entirely-pure kit.LoadRuntimeConfig / SaveRuntimeConfig file I/O + validation. The get special-cases live here too (engine.* resolved via kit.ResolveRuntime; secret_backend via the resolved credential store), in resolveSettingsGet. The THREE credential-store touches (vnc.password.* get/set/delete + secret_backend reset/name) dispatch verb:credential DIRECTLY via InvokeProvider — the same plugin-side pattern candy/plugin-pod/enc_cmd.go proves. The “settings” HostBuild seam (charly/host_build_settings.go) is RETIRED: the plugin already holds a real reverse-channel *sdk.Executor at Invoke(OpRun), so there is nothing left for core to do. This is the same “plugin owns the command AND its logic” doctrine the vm + pod deploy plugins established.
settings is COMPILED-IN (listed in charly/charly.yml compiled_plugins) BECAUSE its Invoke(OpRun) needs the in-proc reverse channel — threaded by dispatchInProcCommand (“Seam A”) — for its verb:credential InvokeProvider calls. The out-of-process CliMain path has no reverse channel, so it errors: settings cannot run out-of-process. There is NO hidden core-command forward and NO core config seam — the plugin does the config I/O itself, reaching only verb:credential over the reverse channel; no core symbol crosses the boundary, no ad-hoc podman.
command:settings dispatches through the COMPILED-IN registry path (registerCompiledPlugin
→ resolve(ClassCommand,“settings”) → dispatchInProcCommand → Invoke(OpRun) with the
threaded in-proc reverse channel), so NewMeta advertises command:settings while the
served CUE schema carries no plugin_input (the args are plain CLI tokens). The R10 witness
is the disposable check-commands-local bed: charly settings list exits 0 and lists the
resolved runtime-config keys, proving the externalized command + its plugin-owned
config I/O end-to-end.
See also the candy reference for this candy’s install surface.