mix logos.remsh (Logos v0.2.0)

Attaches an interactive REPL to a running, distributed Logos node, mirroring iex --remsh. The target host application must already be running as a distributed node (started with --sname/--name and a shared cookie) and must have registered its Logos.Runtime(s) by name via Logos.Runtime.Registry. Each form entered here is shipped via :rpc.call to the target node and evaluated there -- this session never reads the target's ETS tables directly.

Usage

mix logos.remsh --sname my-remsh --cookie secret --target host@node --runtime my-runtime

or with a full --name instead of --sname:

mix logos.remsh --name my-remsh@127.0.0.1 --cookie secret --target host@node --runtime my-runtime

--sname/--name -- this session's own distributed node name (Node.start/2) -- required, one or the other.
--cookie -- the shared distribution cookie (Node.set_cookie/2) -- required.
--target -- the running host app's node name to attach to (Node.connect/1) -- required.
--runtime -- the name the host app registered its Logos.Runtime under via Logos.Runtime.Registry.register/2 -- required.

Every entered form is shipped to the target node via :rpc.call(target, Logos.Repl, :remote_eval, [runtime_name, source, ns]) -- see Logos.Repl.remote_eval/3's own doc for the RPC entry point's exact shape and why only the printed result crosses back over the wire, never a raw Logos.Value.t(). History vars (*1/*2/*3/*e) are interned into the target node's Runtime by that same call (it reuses Logos.Repl.eval_and_print/3 internally), exactly like a local logos.repl session would.

What is/isn't verified (read before trusting this against a real

cluster)

This module's real distributed-Erlang plumbing (Node.start/2, Node.set_cookie/2, Node.connect/1, :rpc.call/4) is not exercised by any automated test in this codebase -- standing up two genuinely separate BEAM nodes (or even one :peer-spawned satellite node) inside a typical sandbox/CI environment is impractical, and that gap is flagged here honestly rather than silently left undocumented. What is unit-tested directly (test/logos/repl_test.exs) is the RPC entry point itself, Logos.Repl.remote_eval/3, called in-process (same node) exactly the way :rpc.call/4 would invoke it remotely -- proving its own contract (looks the Runtime up by name via Logos.Runtime.Registry, evaluates, returns a plain %{printed:, ns:, ok?:} map) independent of whether real distribution is wired up. Node.connect/1/:rpc.call/4 themselves are standard, heavily-used Erlang/OTP distribution primitives -- the risk this module actually carries is entirely in "did we call them with the right arguments/shape", which the entry-point test does cover.