xpando

Overview ¶

Command xpando composes a Pando binary from the public core plus one or more extension modules.

It is the Pando equivalent of xcaddy: extensions are Go packages linked in at build time, so "installing" one means producing a new binary. xpando does that mechanically — it generates a throwaway main module whose main.go blank imports every requested extension package, resolves it with the normal Go toolchain, and builds it.

xpando is internal build tooling. Customers receive a compiled binary and never run this command, which is why there is no module registry, lockfile, checksum database or signature verification here: the modules it links are ones we already control.

xpando build [core-version]
    --with     module[/pkg][@version][=/local/path]   (repeatable)
    --replace  module[@version]=replacement           (repeatable)
    --tags     enterprise,cuda
    --output   ./pando-enterprise
    --ldflags  "-X ...=..."
    --variant  enterprise

GOOS, GOARCH, GOARM and CGO_ENABLED are read from the environment and passed through to the build, so cross-compiling is the same as it is for a plain `go build`.

Private modules need no special handling beyond the usual Go setup:

export GOPRIVATE=github.com/digiogithub/alchemai-agent
git config --global url."git@github.com-josedigio:digiogithub/".insteadOf "https://github.com/digiogithub/"

Caveat: the WebUI is embedded in the core module at *its* publish time (internal/api/webui/dist), and //go:embed cannot cross module boundaries. A composed binary therefore ships the stock frontend unless an extension module supplies its own assets.