mecha10-cli 0.6.3

Mecha10 CLI tool
Documentation 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74

//! Dev mode operations (simulator, teleop, etc.)
//!
//! Helper functions for development mode operations.
//! Extracted from the dev handler to reduce complexity.
//!
//! Split into a few focused submodules, re-exported here so callers keep
//! using `ops::function_name` exactly as before:
//!
//! - [`setup`]: Docker services + Redis connection setup
//! - [`models`]: AI model availability checks before spawning nodes
//! - [`spawn`]: spawning nodes by name (node-runner or standalone)
//! - [`build`]: building node binaries before spawning
//! - [`lifecycle`]: watch mode, cleanup, and lifecycle mode changes
//! - [`interactive`]: the interactive TUI event loop
//! - [`health_tail`]: relays node-runner's health-check/restart log lines into the dev-mode
//!   TUI's log buffer (see LAB-1892)
//! - [`teleop`]: entering teleop control mode
//! - [`preflight`]: project-level Python dependency preflight gate, run once before any node
//!   is spawned (see LAB-1811)
//! - [`registry`]: `NodeRegistry`, the single owner of node PID/failure state (see LAB-1891)

mod build;
mod health_tail;
mod interactive;
mod lifecycle;
mod models;
mod preflight;
mod registry;
mod setup;
mod spawn;
mod teleop;

/// Strip a `@scope/name` node identifier down to its bare short name.
///
/// `NodeRegistry` (and, before it, the `pids`/`start_failures`/`last_known_failures`
/// collections it consolidates - see LAB-1891) is keyed by the full scoped identifier exactly as
/// it appears in `mecha10.json` (e.g. `@mecha10/teleop`) — see `spawn_node_runner`'s "Register
/// with full identifier ... for consistent tracking" — so any code that wants to match those
/// keys against a bare short name (e.g. `"teleop"`) needs to normalize first. This is the one
/// shared implementation - see `mecha10_cli_core::utils::strip_node_scope` for the canonical
/// definition; everywhere else that needs this (including `bin/mecha10_remote.rs`) calls through
/// it too.
pub(crate) use mecha10_cli_core::utils::strip_node_scope;

pub use build::build_nodes;
pub use interactive::{run_interactive_mode, InteractiveModeConfig, InteractiveModeState};
pub use preflight::run_dependency_preflight;
// `NodeState` isn't consumed by any call site yet (see its own docs on `NodeRegistry::state`/
// `NodeRegistry::snapshot` for why it's kept anyway), but it's part of the pre-existing `ops::`
// public surface convention (same rationale as `SpawnOutcome`/`cleanup`/`enter_teleop_mode`
// below), so it stays re-exported here.
#[allow(unused_imports)]
pub use registry::{NodeRegistry, NodeState};
pub use setup::{setup_redis_connection, start_docker_services};
pub use spawn::{spawn_nodes_by_name, SIM_VISIBLE_ENV_VAR};
// Shared with `handlers::run::run_robot_target` so `mecha10 run robot` injects the same
// locomotion env vars into the binary it execs directly as `mecha10 dev` injects for its
// node-runner/direct-spawn paths (see that function's docs for the root-cause bug this fixes).
pub(crate) use spawn::maybe_inject_teleop_locomotion_env;
// `SpawnOutcome` is only constructed/consumed via direct submodule paths today, but it's
// part of the pre-existing `ops::` public surface, so it stays re-exported here for API
// compatibility (same rationale as `cleanup`/`enter_teleop_mode` below).
#[allow(unused_imports)]
pub use spawn::SpawnOutcome;

// `cleanup` and `enter_teleop_mode` are only called from within this module tree today
// (via direct submodule paths), but they're part of the pre-existing `ops::` public
// surface, so they stay re-exported here for API compatibility. The bin target has no
// external consumer of that surface, hence the lint allow.
#[allow(unused_imports)]
pub use lifecycle::cleanup;
pub use lifecycle::run_watch_mode;
#[allow(unused_imports)]
pub use teleop::enter_teleop_mode;