Skip to content
OpenCharly

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

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:

  • apk-install — step class
  • builder — step class
  • file — step class
  • local-pkg-install — step class
  • op — step class
  • reboot — step class
  • repo-change — step class
  • service-custom — step class
  • service-packaged — step class
  • shell-hook — step class
  • shell-snippet — step class
  • system-packages — step class

What it does

Section titled “What it does”

Compiled-in DUAL-PLACEMENT charly class:step plugin serving the BUILD-context OpEmit leg for the compiler-emitted builtin InstallStep kinds. Two sub-categories: the PURE kinds (C1.1) — file, shell-hook, shell-snippet, service-packaged, service-custom, repo-change, apk-install, plus the no-op-emit reboot (C1.6) — whose fragment is pure string formatting from the compiler-produced spec.InstallStepView (the SAME view the deploy walk consumes), so the plugin returns the pod-overlay Containerfile fragment directly from OpEmit (apk-install and reboot declare Emits=false and return an empty fragment — an image build installs no apk / reboots nothing); and the HOST-COUPLED system-packages (C1.2) + builder (C1.3) + local-pkg-install (C1.4) + op (C1.5) kinds, whose build-context render needs box/candy/distro/builder STRUCTURE a bare step view cannot carry. Rather than calling back a host-side renderer, this plugin fetches the “resolved-project” envelope ONCE per project dir (InvokeProvider(“build”,“project”), cached — the SAME generic seam candy/plugin-box/plugin-bundle/plugin-check consume) and builds its OWN *deploykit.Generator from it via the SAME deploykit.NewRenderGeneratorFromProject helper candy/plugin-build (the box-build render) and candy/plugin-deploy-pod (the overlay render) use, then renders each fragment DIRECTLY (dg.EmitTasks / dg.BuildStageContext / kit.BuilderResolve / deploykit.RenderLocalPkgImageInstall) — NO per-render host round-trip. The few per-invocation scalars a resolved-project snapshot cannot carry (which box, a dev-bed build, an Op step’s inline-content staging dir) ride the SAME OpEmit Invoke’s spec.BuildEnv (op.Env) every word already receives. The DEPLOY leg for ALL these kinds STAYS unchanged in sdk/kit.WalkPlans (system-packages + builder + local-pkg-install are host-engine kinds driven via RunHostStep → deploykit.RenderHostPackageCommand / runVenueBuilderStep / deploykit.ExecLocalPkgInstall; op is the act-OpStep resolveProvisionScript / renderOpCommand path; reboot is the host-side guest reboot via RunHostStep → rebootVenueAndWait, driven only on a rebootable VM venue); this plugin serves ONLY OpEmit. Every InstallStep kind is plugin-served (12 via this candy; ExternalPlugin via its own class:step plugin dispatch), and the former in-core “step-emit” per-word renderers (charly/step_emit_hostbuild.go’s stepEmitSystemPackages/stepEmitBuilder/ stepEmitLocalPkgInstall/stepEmitOp) are GONE — only the unrelated “oci-emit-step” word (the pod-overlay candy’s own per-step render request, needing the FULL core provider-registry dispatch) remains on that seam. Its Go lives in this candy’s own module (NewProvider/NewMeta + a cmd/serve out-of-process shim), compiled INTO charly via charly.yml compiled_plugins:.

Parameter schema

Section titled “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/installstep.cue

Section titled “schema/installstep.cue”
// schema/installstep.cue — the (vestigial) CUE schema for the compiled-in class:step build-emit
// plugin. The InstallStep kinds it serves (file / shell-hook / shell-snippet / service-packaged /
// service-custom / repo-change / apk-install / reboot / system-packages / builder / local-pkg-install /
// op) are COMPILER-EMITTED from
// declarative candy fields (copy:/env:/service:/package:/pixi.toml/Cargo.toml/reboot:/…), never authored as
// a `plugin:` step, so
// NO capability declares an InputDef. This def exists ONLY to satisfy the plugin load gate (every
// plugin MUST ship a non-empty CUE schema that splices onto charly's base). The OpEmit payload is
// a spec.InstallStepView (the compiler's step serialization), decoded directly in Go.
#InstallStepBuildEmit: {
  // Placeholder — the real OpEmit payload is spec.InstallStepView, not an authored plugin_input.
  kind?: string
}

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