Flopsy plugins extend the input-deck syntax registry.
A runtime plugin package must provide:
register_flopsy_plugin!(registry)Inside that function, the plugin registers additional SyntaxSpec entries.
The CLI discovers runtime plugins from a managed Julia environment under the user config directory.
This keeps the compiled CLI stable while still allowing new syntax to be installed after the app is built.
Operationally:
- Flopsy creates or reuses the managed plugin environment.
- Registered plugin packages are loaded from that environment.
- Each plugin's
register_flopsy_plugin!(registry)function is invoked. - Plugin load failures are recorded and surfaced through
plugin listand CLI errors.
List installed plugins:
julia --project=. scripts/flopsy.jl plugin listRegister a local plugin:
julia --project=. scripts/flopsy.jl plugin register MyPlugin --path /path/to/MyPluginRegister from a package URL:
julia --project=. scripts/flopsy.jl plugin register MyPlugin --url https://example.com/MyPlugin.jl.gitRemove a plugin:
julia --project=. scripts/flopsy.jl plugin remove MyPluginOnce a plugin is installed and loaded successfully, its registered syntax appears alongside built-ins in:
syntax listsyntax show <domain> <type>
Users then reference the plugin's registered (domain, type) pairs in normal input-deck blocks. Plugins do not invent new top-level TOML domains.
The Palioxis integration in ext/PalioxisExt.jl follows the same registration model conceptually:
- it contributes backend/IC syntax through the registry
- it coexists with built-in syntax
- if unavailable, its syntax is simply absent rather than partially parsed by a special TOML path