CLI & System Management
Lifecycle and Status Management
Section titled “Lifecycle and Status Management”The CLI provides direct commands for controlling the server’s operational state. Users can start, stop, restart, and check the status of the server and its backend components 1. Additionally, the logs command allows users to tail server logs for debugging. The status command specifically checks both the server and backend status.
Configuration and Environment Loading
Section titled “Configuration and Environment Loading”Configuration management is handled through the _load_dotenv_into_environ function, which ensures every CLI subcommand sees the same backend URLs as the running server. This function delegates to config.load_deployment_env but skips specific keys owned by the start command. The start command derives the admin bind host/port itself (443 on the AP IP), and injecting legacy SCRIBE_PORT=8080 or SCRIBE_HOST=0.0.0.0 from .env would cause the server to bind the wrong port and crash on startup.
Command Registration and Module Structure
Section titled “Command Registration and Module Structure”Commands are organized into topic modules under meeting_scribe.cli.<topic>. Importing these modules triggers their decorators, registering commands on the root cli group. The import order is significant because some modules alias commands from others; for example, up/down proxy the gb10 group, so gb10 is imported before setup. The following modules are registered: appliance, audio, bench, benchmark, bootstrap, bt, clean_slate, config, debug, demo_smoke, diarization, doctor, finalize, gb10, hf_probe, host_setup, images, install_service, k3s, kiosk, library, lifecycle, meetings, operator, precommit, provision, queue, remote_desktop, setup, speakerphone, terminal, trust, upgrade, validate, versions, and wifi.
Versioning
Section titled “Versioning”The CLI includes a --version option that reflects the actual deployed package version. The _resolved_version function reads the version from importlib.metadata to avoid hardcoded literals that may drift across releases. If the package is not found, it returns "0.0.0+unknown".
"""Meeting Scribe CLI - manage server lifecycle and development tools.
Usage:
meeting-scribe start # Start the server
meeting-scribe stop # Stop gracefully
meeting-scribe restart # Stop + start
meeting-scribe status # Check server + backend status
meeting-scribe logs # Tail server logs
The ``cli`` group is defined here; topic modules under
``meeting_scribe.cli.<topic>`` register their commands by importing
this module and decorating with ``@cli.command()`` or
``@<group>.command()``. The ``main`` entry point is what
``[project.scripts]`` in pyproject.toml resolves to.
"""
from __future__ import annotations
from importlib.metadata import PackageNotFoundError
from importlib.metadata import version as _pkg_version
import click
# Listener bind config is owned by the ``start`` command (admin HTTPS on 443
# at the AP IP), NOT by ``.env`` - which carries a legacy SCRIBE_PORT=8080 /
# SCRIBE_HOST=0.0.0.0 that would crash startup if injected. Never load these.
_LISTENER_OWNED = frozenset({"SCRIBE_PORT", "SCRIBE_HOST", "SCRIBE_CAPTIVE_HTTP_PORT"})
def _load_dotenv_into_environ() -> None:
"""Load the deployment ``.env`` so every CLI subcommand sees the same
backend URLs the running server does (the canonical loader lives in
``config.load_deployment_env``; standalone tools call it too).
``_LISTENER_OWNED`` keys are skipped: the ``start`` command derives the
admin bind host/port itself (443 on the AP IP), and ``.env`` carries a
legacy ``SCRIBE_PORT=8080`` / ``SCRIBE_HOST=0.0.0.0`` that, if injected
here, makes the server try to bind the wrong port and crash on startup.
"""
from meeting_scribe.config import load_deployment_env