Module env 

issue 0687 — the hosted edge of configuration: every env var nano-ros honours is read here, and the core takes values. The hosted edge of configuration: the process environment.

issue 0687 / phase-359 W10. Every env var nano-ros honours is read HERE and nowhere else. The core (nros-node) takes values — ExecutorConfig:: resolve_with accepts an EnvRung of already-resolved fields — so it needs no std, no env capability, and no stub on the five ports that have no environment to read.

That is the difference between this and the ABI ports W10 made for the clock, sleep, tasks and the log sink: those name capabilities every RTOS HAS. A process environment is not one. Modelling it as an ABI entry would have put return 0 in five ports and permanent surface in the header, for a facility that exists on one platform family.

What lives here:

• ExecutorConfigEnvExt::from_env — the constructor that used to be an inherent method on ExecutorConfig. Bring the trait into scope (the prelude has it) and the call site spelling is unchanged.
• resolve_hosted / try_resolve_hosted — RFC-0045 precedence model A with the environment rung on top. These replace the old ExecutorConfig::resolve(baked, hosted_env: bool), whose flag was a compile-time constant at every call site in the tree: true at exactly one board plus the two FFI entries, false everywhere else.
• rmw_selector — the one $NROS_RMW reader (issue 0687’s first half).

Traits

ExecutorConfigEnvExt

ExecutorConfig::from_env(), as an extension trait.

Functions

resolve_hosted

RFC-0045 precedence model A with the environment on top: env (var set) > baked > compiled default.

rmw_selector

The answer to “which RMW backend did the user select” — one reader, one semantic, for every consumer.

try_resolve_hosted

Fallible resolve_hosted — returns BootConfigError instead of panicking, so the C / C++ FFI shims can surface a return code.