ROS 2 bridge is Humble-only (YAML bridge + Python Ros2Context): expose distro feature, make Python bridge optional, per-distro builds? #3554

The workspace Cargo.toml pins ros2-client = { …, features = ["humble"] }, so every published ROS 2 bridge build is Humble-only. On a Jazzy system:

ERROR ros2_client::distributions: ROS_DISTRO='jazzy' but ros2-client was built for 'humble'. … rebuild with --features jazzy.

No dora crate forwards that feature, so the only fix today is patching the workspace manifest and rebuilding from source. The only distro-gated code in ros2-client is GID_LENGTH (24 bytes ≤ humble, 16 bytes ≥ iron); dora never touches Gid on the DDS path and its zenoh transport already uses [u8; 16], so a jazzy build needs no code changes — it just trades Humble interop for Jazzy interop (graph discovery, services).

This affects both bridge surfaces differently:

YAML bridge (dora-ros2-bridge-node) — the binary isn't distributed at all: the crate is publish = false, the dora-rs-cli wheel and dora-cli-*.tar.gz release assets only contain dora, and the CLI's node_binary::find() auto-build fallback is only wired up for dora-record-node/dora-replay-node. The ros2: block is rewritten to a custom node with path: dora-ros2-bridge-node and spawned by name from $PATH. So every user already builds it from a repo checkout; a distro feature would at least let that build target the right ROS version.

In-process Python (from dora import Ros2Context) — the dora-rs wheel links dora-ros2-bridge-python unconditionally, so Ros2Context is Humble-pinned for every Python user and, unlike the node binary, can't be swapped out: fixing it means rebuilding the entire dora-rs wheel with maturin. A dataflow mixing a patched YAML bridge with Ros2Context ends up with one Jazzy participant and one Humble participant from the same repo.

Jazzy is the current LTS and the ROS 2 version shipped with NVIDIA JetPack 7.

Proposal

1. In dora-ros2-bridge, drop the workspace pin and add mutually exclusive features mapped to ros2-client's chain, defaulting to humble so nothing changes for existing users:

   [features]
   default = ["generate-messages", "ros2-humble"]
   ros2-humble = ["ros2-client/humble"]
   ros2-jazzy  = ["ros2-client/jazzy"]
   # + iron / kilted, and a compile_error! if more than one is set

   Forward them through dora-ros2-bridge-node and dora-ros2-bridge-python (same pattern as the existing tensor-pool pass-through in dora-cli). With just this, cargo install --git … dora-ros2-bridge-node --features ros2-jazzy works for the YAML side.
2. Make the ROS 2 bridge optional in the Python package: a base dora-rs wheel without dora-ros2-bridge-python, and the bridge as its own wheel (it already builds standalone in scripts/ros2-zenoh-interop.sh), e.g. dora-rs[ros2-humble] / dora-rs[ros2-jazzy] extras. This keeps the DDS stack out of non-ROS installs and makes the ROS part small enough to publish per distro.
3. Question for maintainers: would you be willing to ship per-distro builds (Humble + Jazzy) for both surfaces — release assets for dora-ros2-bridge-node and per-distro Python bridge wheels? With the bridge split out that's a small matrix (2 distros × existing targets), and the nightly ros2-zenoh-humble interop job would need a jazzy twin.
4. Docs, regardless of (3). The guide currently never says how to obtain either bridge (the Prerequisites section only mentions a sourced ROS 2 env and message packages). Please add a "Building the bridge for your ROS distro" page covering both surfaces:
   • YAML bridge: how to build dora-ros2-bridge-node from a checkout for a given distro and put it on PATH (e.g. cargo install --git https://github.com/dora-rs/dora --tag vX.Y.Z dora-ros2-bridge-node --no-default-features --features ros2-jazzy), and that dora run finds it via $PATH.
   • In-process Python: how a user on a non-Humble distro rebuilds the Python bridge with maturin and the matching feature so from dora import Ros2Context works (today: rebuild the whole dora-rs wheel; with (2): just the bridge wheel).
     If you decide not to publish per-distro wheels/assets, this is the minimum that makes the feature from (1) usable.

Longer term, the matrix could go away entirely if ros2-client selected the Gid layout at runtime from ROS_DISTRO (it already reads it for the check above) — though that also touches RustDDS's static key-hash size rule for the ros_discovery_info key, so it's an upstream change rather than a dora one.