plugin-ollama

Version	2026.229.1013
Repo	box/github.com/opencharly/plugin-ollama:v2026.237.1426
Plugin	yes — see the plugin reference

COMPILED-IN charly COMMAND-class plugin (command:ollama) OWNING the entire charly ollama CLI — the host-side management surface for a DEPLOYED Ollama server: list / ps / pull / rm / show / cp / create / push / run / stop / version. The plugin owns the ENTIRE logic: the hand-rolled subcommand grammar AND the Ollama HTTP API calls, built on the official upstream Go client (github.com/ollama/ollama/api, pinned in the candy’s own go.mod). There is NO core ollama logic and NO HostBuild seam.

The command talks to the server over plain HTTP, so it is fully self-contained and works IDENTICALLY compiled-in OR out-of-process: listed in charly.yml compiled_plugins it registers in-proc and the host dispatches it through dispatchInProcCommand → Invoke(OpRun) → runOllamaCLI; the out-of-process placement fork/execs cmd/serve → CliMain running the SAME runOllamaCLI. Endpoint resolution is deliberately lightweight: –server flag > OLLAMA_HOST env

http://127.0.0.1:11434.

This is a sibling of the ollama CANDY (candy/ollama — which deploys the server) and of the candy’s host shell alias: ollama (which execs the upstream CLI inside the container): three disjoint surfaces. Full Modelfile authoring stays with the upstream CLI; charly ollama create covers the lightweight –from form.

The R10 witness is the disposable check-ollama-pod bed (box/fedora): it deploys the ollama image and runs charly ollama list|version --server http://127.0.0.1:${HOST_PORT:11434} host-side against the live server, plus the candy’s baked checks.

Acceptance plan

This candy’s plan: — the runnable spec charly check executes against a live deployment. check: steps are idempotent probes; run: steps change state.

Intent	Step
check	the command plugin ships a buildable Go module (go.mod + the provider) the host can build; the full charly ollama end-to-end is exercised by the live R10 bed (check-ollama-pod)