Base Plugins

The base plugin defines the callbacks every other plugin can implement and ships the global options/flags that apply to every command. It is always loaded.

The other always-loaded plugins — Setup, Build, Run, Mcp — sit on top of Base and form the @base_plugins set defined in lib/marea.ex. Note that the MCP Plugin re-exposes every leaf subcommand contributed by any other loaded plugin as a typed MCP tool, with no extra work on the contributing plugin's side.

When it's loaded

Marea.Plugins.Base is always part of @base_plugins in lib/marea.ex, so you don't list it in plugins:.

Callbacks defined

Implementations are no-ops; their job is to define the chain entry points other plugins implement. See 06-plugin-development.md for the intended return values.

Marea.Plugins.Docker declares one additional callback, Marea.Plugins.Docker.marea_dockerfile_assigns/2, for plugins that want to enrich the EEx assigns Marea passes to the rendered Dockerfile (docker.python uses it to inject a Python build stage).

Global options and flags

These are declared in Marea.Config.Args.base_args/0 and tagged global: true. The args builder injects them into every leaf subcommand, so they're available everywhere:

Reusable option specs

Marea.Config.Args ships a few helpers other plugins use to keep CLI surface consistent:

Command-handling helpers

The Base plugin also documents the conventional return values from Marea.Plugins.Base.marea_cmd/2. Implementations in other plugins should:

• match their command prefix (e.g. [:helm | rest]);

• return :cont for everything else, so the chain continues to the next plugin;
• return :usage for an unrecognised subcommand to print help.

defcb marea_cmd([:my_cmd | rest], %Config{} = config), do: my_cmd(rest, config)
defcb marea_cmd(_cmds, _config), do: :cont

Built-in commands

Base also ships one user-facing command for inspecting the live, plugin-enriched schema:

marea schema
└── show    [--json]

marea schema show

Prints a readable, indented tree of every field in the plugin-enriched schema, with type, required/default, and description.

The schema is rebuilt on every invocation by running the Marea.Plugins.Base.marea_config_schema/1 plugin chain, so any fields contributed by plugins listed in marea.yaml (e.g. Marea.Plugins.Aws adding aws:) appear in the output.

Sample output (trimmed):

:plugins (array<string>) = []
:marea_dir (string) = "marea.d"
:state_dir (string) = ".marea"
:cmd_prefix (map)
  :build (string)
      Shell prefix wrapping every command tagged `prefix: :build` …
:deploys (map<string, map>)
  :<string> (map)
    :type (enum(:helm)) = :helm
        Deploy type
    :releases (map<string, map>)
      :<string> (map)
        :type (enum(:elixir | :dockerfile_dir)) = :elixir
            Build strategy. :elixir auto-generates a Dockerfile …
        …

Conventions in the tree:

• key (type) — the field name and a compact type label.
• = <value> — the field has a default; the value is shown verbatim.
• (required) — the field has no default and must be set.
• :<string> / :<any> — the parent is a dynamic-key map (e.g. one entry per deploy / release / aws-id); the inner schema applies to every key.
• The first indented line under a field is its description, when the schema declared one.

Flags

The --json form is meant for machine consumption: piping into jq, generating editor completions, or feeding tools that already speak JSON Schema.

marea schema show --json | jq '.properties.deploys'

Implementation notes

• The tree formatter walks Zoi type structs directly (the internal Map / Default / Array / Enum types) and unwraps Default to surface the default value while still reporting the inner type.
• Zoi.optional/1 doesn't wrap — it just sets meta.required = false on the inner node — so the formatter checks meta.required to decide whether to print (required).
• Dynamic-key maps (Zoi.map(key_type, value_type)) are rendered as map<key, value> with a single placeholder child key; this matches how the schema is defined for deploys, releases, aws, and route53 zones.