Documentation
¶
Overview ¶
Package plugin wires `w17ctl plugin <leaf>` — the plugin catalogue commands (list / install / update / gen-pb). The catalogue is SERVED BY THE CONSOLE (ListPluginCatalog / FetchPlugin); the client carries no copy, so a plugin change reaches a consumer through a console deploy rather than through a client release. This package owns the install/update logic and nothing else.
Index ¶
Constants ¶
const DefaultPluginsRepo = "https://github.com/wandering-compiler/plugins"
DefaultPluginsRepo is where a bare plugin NAME resolves to.
`w17ctl plugin install auth` is sugar for the organisation's own registry — the same mechanism as any other repository, with the URL filled in. It is a client-side default, like the compile-time console address, and not a rule about plugins: pointing it elsewhere with W17_PLUGINS_REPO changes which registry "by name" means, and spelling the repository out always wins.
The console used to answer this question by SERVING the plugin's bytes from a catalogue compiled into it. That made the console a file server for plugins and a second source of truth beside the registry, which is what this replaced.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Cmd ¶
type Cmd struct {
List ListCmd `cmd:"" help:"List the console's plugin catalogue + each plugin's install state in this project's lock."`
Install InstallCmd `` /* 324-byte string literal not displayed */
Update UpdateCmd `` /* 298-byte string literal not displayed */
GenPb GenPbCmd `` /* 145-byte string literal not displayed */
}
Cmd is the parent of `w17ctl plugin <leaf>` commands:
- `list` — inventory of the console's catalogue + installed plugins
- `install` — fetch one plugin into the project's `<proto_dir>/plugins/` tree + record it in the lock. Two sources: a NAME, served from the console's catalogue, or a RELEASE in a repository, spelled `<repo>#<plugin>/<version>`. The fragment is the git tag itself, so what an operator types is what the repository carries. A repository install also records the commit that tag resolved to and the digest of the tree that landed, so the lock pins which BYTES were installed and not only which version number
- `update` — re-fetch one (or every) installed plugin from the console's catalogue, refreshing the on-disk tree + the lock version
`remove` is a v2 feature; until then operators manually `rm -rf <proto_dir>/plugins/<name>/` + drop the lock entry.
type GenPbCmd ¶
type GenPbCmd struct {
Dir string `` /* 137-byte string literal not displayed */
Console string `` /* 175-byte string literal not displayed */
}
GenPbCmd implements `w17ctl plugin gen-pb [dir]`.
It regenerates a plugin's standalone `src/gen/pb/*.pb.go` from its `proto/` tree — the committed pb files that exist ONLY for the plugin author's local dev/test loop (`go test ./...` inside `src/`). The project codegen pipeline generates its OWN per-activation pb at staging time and never uses these files.
Thin-client model: the compile is a COMPILER concern, so it runs on the console. The client only uploads the raw proto/ tree + plugin.yaml to the GeneratePluginPb RPC, and writes the pb.go files the server returns — no buf / loader / manifest / placeholder logic client-side.
type InstallCmd ¶
type InstallCmd struct {
Source string `` /* 130-byte string literal not displayed */
Console string `` /* 214-byte string literal not displayed */
}
InstallCmd implements `w17ctl plugin install <name|url>`.
v1 supports name-only — the named plugin must exist in the console's catalogue. URLs are accepted at the argument layer to reserve the surface for v2 but rejected at the handler with a steering message.
Install:
- Resolve the project root + lock.
- Refuse if `<name>` is already in lock.plugins[], or if `<root>/<proto_dir>/plugins/<name>/` already exists — v1 has no `remove`, so the operator cleans up first. Both are local checks and run BEFORE the console is dialled: a repeat install should not stream a plugin tree only to refuse it.
- Stream the plugin from the console into a sibling STAGING dir.
- Validate the staged plugin.yaml server-side (InspectPluginManifest): manifest errors, name/dir disagreement, requirement warnings.
- Append `PluginInstall{name, version, source: "internal"}` to the lock via EditLock (the server appends + re-signs).
- Only then rename the staged tree into place.
func (*InstallCmd) Run ¶
func (c *InstallCmd) Run() error
type ListCmd ¶
type ListCmd struct {
LockPath string `name:"lock" placeholder:"PATH" default:"w17/lock.yaml" help:"Path to the lock file."`
Console string `` /* 189-byte string literal not displayed */
}
ListCmd implements `w17ctl plugin list`. Asks the console for its plugin catalogue and cross-references the lock's `plugins[]` to surface install state. One line per plugin; reports "no plugins available" when the console serves none and the lock records none.
type UpdateCmd ¶
type UpdateCmd struct {
Name string `arg:"" optional:"" name:"name" help:"Installed plugin to refresh. Mutually exclusive with --all."`
All bool `name:"all" help:"Update every plugin recorded in lock.plugins[]."`
To string `` /* 238-byte string literal not displayed */
Console string `` /* 214-byte string literal not displayed */
}
UpdateCmd implements `w17ctl plugin update <name>` and `w17ctl plugin update --all`. Both branches share the same per-plugin logic; --all just iterates over every installed plugin in the lock.
Per-plugin update:
- Lock entry must exist for `<name>` (otherwise the operator wants `plugin install` instead).
- The console's catalogue must carry `<name>` (URL-installed plugins can't be updated through this path).
- The fetched manifest is validated server-side; CheckRequires runs against the running w17 version.
- The refreshed tree is staged, then swapped in. The manifest's `version` becomes the new `lock.plugins[].version`.
- Lock is re-signed once at the end (one save per command run regardless of how many plugins update).