Plugin manifest

A plugin describes itself to an Open Meridian deployment in its own pyproject.toml, under [tool.meridian]. meridian plugin upload reads it and sends it with the plugin's image, and the deployment records it with the version.

These are declarations, not grants. What a plugin may do comes from the roles a deployment admin approves when a version is launched, never from the plugin's code. See Plugins, roles and grants.

The template's manifest

meridian plugin new writes this. The names shown are the reference plugin's.

pyproject.toml

[project]
name = "reference-plugin"
version = "0.1.0"
description = "A Meridian plugin"
requires-python = ">=3.11"
dependencies = ["open-meridian==0.36.0"]

[project.scripts]
reference-plugin = "reference_plugin.__main__:main"

[tool.meridian]
roles = []
interface = true
declaration = "reference_plugin.declaration:DECLARATION"

[tool.meridian]

The table must be present: an upload without it is refused. The command line reads these three keys, and refuses tags (below).

Key	Type	Default when absent	Meaning
roles	list of strings	[]	The roles the plugin asks for, from the deployment's fixed list (below). Its grants on the bus are the union of its roles' grants. Empty is a plugin admitted with no topics, as the reference plugin is.
interface	boolean	false	Whether the plugin serves a page through its sidecar. It is shown in the catalogue (page: yes or no in meridian plugin list).
name	string	[project] name	The plugin's name in Meridian, apart from its Python project: its registry listing, plugin publish and plugin release (the push scope too) and plugin upload's catalogue entry use it. A project named plugin-databento lists as databento with name = "databento".
declaration	string	none	The version's declaration, as "<module>:<attribute>", naming a meridian.Declaration: its settings, its interface, whether it reads external accounts and its documentation. meridian plugin upload reads it from the built image with meridian-declaration, and the texts in docs/ beside it. A plugin on SDK 0.29.0 names one: a version uploaded without it is refused at registration. meridian plugin check fails one naming a module or an attribute the plugin does not have. See The whole declaration.

Rules

The command line checks these before anything is built or sent:

• roles is a list, and every item in it is a string.
• Every role is a name: 1 to 63 characters of lowercase letters, digits and single hyphens, starting with a letter and not ending with a hyphen.
• There is no tags key. A [tool.meridian] that declares one, even tags = [], is refused (see below).

The deployment checks these again when it records the version, and also refuses:

• a role that is not on the deployment's list;
• a role that is one of the deployment's own components, which no plugin may declare: conductor, dashboard, street, instrument, first-run, launcher, sidecar;
• a role declared twice.

Roles

A plugin's roles come from this list of fifteen, from the deployment's contract. The template's comment lists them.

Role	For
compliance	pre- and post-trade compliance rules
confirmation	confirmation with external matching services
connectivity	broker and venue connectivity
custody	custodian, prime broker and broker positions and reconciliation
data	external data ingress
ems	execution management
oms	order management, including tax-lot selection
operations	the post-trade pipeline: matching, servicing, reconciliation, settlement
portfolio	portfolio construction
pricing	pricing models: answers the analytics component's batches for the models its version declares.
reference	reference and terms data: a security's terms gathered, reconciled and offered to the instrument store.
reporting	reporting, analytics and valuation
servicing	non-trading transactions: corporate actions, lifecycle events, coupons
settlement	external settlement rails
signal	signal generation

A role's topics are exactly the rows of the interface that name it, the typed operations it may take; what each role holds is on Roles.

Keys outside [tool.meridian]

The command line also reads these, and refuses an upload without them.

Key	Type	Meaning
[project] name	string	The plugin's name. The same form as a role: lowercase letters, digits and single hyphens, starting with a letter. It names its image and its repository in the deployment's registry, plugins/<name>.
[project] version	string	The version. It must not be empty. The deployment takes 1 to 64 characters of letters, digits, ., _, + and -. A version is recorded once and never replaced.
[project] dependencies	list of strings	Must pin the SDK exactly, as open-meridian==<version>. That version is recorded as the plugin's SDK version, so an admin can see which plugins stand on a base that needs a fix. A range is refused.
[project.scripts]	table	On a development deployment, the live runner starts the first entry point named here, as module:function.

Settings are not declared here

A plugin's settings, and the pages it serves with the levels each serves, are declared in code, in the version's meridian.Declaration, which declaration names. See the Python SDK. The manifest's interface flag and the declaration's interface are separate: nothing in the command line or the recording checks that they agree.

Changing the manifest

Roles and dependencies take a new version, which a person approves

A save changes what a plugin does, never what it is allowed to do. Adding a role to pyproject.toml changes nothing on a running instance, live or not. A new dependency does nothing either: the live code runs on the image the instance was launched from.

To change any of them:

1. Raise version in [project]. A version is never replaced, so uploading one that is already recorded is refused.
2. Upload it with meridian plugin upload, or meridian plugin dev --release.
3. Launch it. The launch shows the roles the version declares, and runs it only once a person approves them.

The deployment runs a launched version with exactly the roles it declares. An approval that names anything else is refused.

--yes on meridian plugin launch and meridian plugin dev approves without asking. It is for a script that has already shown the roles to a person and got their yes, never for getting past a question nobody has answered. See the command line reference.

Who may use a plugin is not declared here

A plugin declares no tags, and nothing else in the manifest says who may use it. A person's level on each of a plugin's roles is admin, read or write, the same for every plugin, granted by a deployment admin in the deployment's access groups; the plugin reads the session's level, and the accounts it reaches, from Caller. Which levels each page serves is declared in code, with meridian.Pages. See Access.

A manifest with tags = [...] in [tool.meridian] needs that line removed: meridian plugin upload refuses it, citing the reason, before anything is built.