exlab_wizard.plugins.logger#
Plugin logger shim. Backend Spec §6.1.4 / §6.3.2.
Plugins call ctx.log.info(...) / ctx.log.warning(...) rather than
print() or logging.getLogger(...) directly because:
In the worker subprocess (the production path),
stdoutis reserved for the IPC envelope – a strayprintcorrupts the protocol. Stderr carries structured log frames the host re-emits into the wizard log.In-process invocations (unit tests,
--no-isolationdebug) need a logger that forwards into the canonicalexlab_wizard.logging.get_logger()chain so log records show up alongside everything else.
The PluginLogger base type is the abstract surface plugins see;
the two implementations – HostPluginLogger (in-process) and
WorkerPluginLogger (subprocess) – share the same four-method
shape (debug / info / warning / error).
Each call accepts a positional message and arbitrary structured
**fields keyword args; the host logger renders them as key=value
extras while the worker logger emits them inside the JSON frame’s
context block (which the host then merges back in). Plugin authors
do not need to know which path they’re on – the API is identical.
Classes
|
In-process forwarder used when plugins run without subprocess isolation. |
|
Wire format for worker-side log records. |
Abstract structured-log interface plugins receive on |
|
|
Worker-side forwarder. |
- class exlab_wizard.plugins.logger.HostPluginLogger(name='exlab_wizard.plugins')[source]#
Bases:
PluginLoggerIn-process forwarder used when plugins run without subprocess isolation.
Used by the host’s unit-test shim, by
--no-isolationdebug invocations of the plugin CLI (Backend Spec §6.10), and by the host when re-emitting parsed worker frames. Routes throughexlab_wizard.logging.get_logger()so records flow into the canonical handler chain (per-equipment file, central rotating, stderr).- Parameters:
name (
str)
- class exlab_wizard.plugins.logger.PluginLogFrame(level: str, message: str, context: dict[str, ~typing.Any]=<factory>)[source]#
Bases:
StructWire format for worker-side log records.
The worker subprocess emits one
PluginLogFrame-shaped JSON object per log line on its stderr stream; the host parses each line and forwards into the canonical logger chain. Backend Spec §6.3.2.
- class exlab_wizard.plugins.logger.PluginLogger[source]#
Bases:
ABCAbstract structured-log interface plugins receive on
ctx.log.Implementations forward to either the in-process stdlib logger (
HostPluginLogger) or the worker stderr channel (WorkerPluginLogger). Both expose the same four-method shape; plugin authors should not reach behind it.
- class exlab_wizard.plugins.logger.WorkerPluginLogger(stream=None)[source]#
Bases:
PluginLoggerWorker-side forwarder. Emits JSON frames on stderr.
Used inside the plugin worker subprocess (Backend Spec §6.3.1). Each call serializes a
PluginLogFrameviamsgspec.jsonand writes a single newline-terminated line to the configured stream (defaults tosys.stderr). The host reads these line-by-line and forwards them to the canonical logger.The worker MUST NOT use stdout for log output – that channel is reserved for the IPC envelope. Stderr is the structured-log sideband.