Add CloudXRLauncher CLI helpers for optional in-process runtime launch.

[nv-jakob]

Expose argparse helpers so embedding apps and examples can default to launching the CloudXR runtime and WSS proxy, with --no-launch-cloudxr-runtime for environments where the runtime is already running.

Description

Partial fix for #696

Fixes #(issue)

Type of change

• New feature (non-breaking change which adds functionality)

Testing

Ran the added test

Checklist

• I have read and understood the contribution guidelines
• I have run the linter and formatter with SKIP=check-copyright-year pre-commit run --all-files
• I have made corresponding changes to the documentation
• I have added tests that prove my fix/feature works (or explained why not)
• I have signed off all my commits (git commit -s) per the DCO

Summary by CodeRabbit

• New Features
  • Added a new command-line option to enable or disable launching the CloudXR runtime.
  • The runtime now supports a “no launch” mode for embedding or external-managed setups, while keeping the default behavior unchanged.

[github-actions]

📝 Docs preview is not auto-deployed for fork PRs.

A maintainer with write access to NVIDIA/IsaacTeleop can deploy a preview by
commenting /preview-docs on this PR. Once deployed, the preview
will live at:

https://nvidia.github.io/IsaacTeleop/preview/pr-700/

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Enterprise

Run ID: d9024f79-db03-4699-b2c3-90e3d7ad7efe

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

📝 Walkthrough

Walkthrough

CloudXRLauncher in launcher.py gains two new static methods: add_launch_cloudxr_runtime_argument, which registers a --launch-cloudxr-runtime / --no-launch-cloudxr-runtime boolean CLI flag (default True) via argparse.BooleanOptionalAction, and launch_context, which returns either a CloudXRLauncher instance or contextlib.nullcontext(None) depending on the parsed flag, forwarding configuration parameters when launching. The argparse and contextlib imports are added accordingly. A new test class TestLaunchArgumentHelpers in the test module covers default flag value, flag negation, context skipping when disabled, and context wiring when enabled.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the main change: new CLI helpers to optionally launch the CloudXR runtime in process.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}

[jiwenc-nv]

since we are here, maybe add a arg for --cloudxr-install-dir as well (default to ~/.cloudxr)

[nv-jakob]

Added

[nv-jakob]

Hmm, is it actually install dir? We don't install anything there right? It's more like run dir right?

[jiwenc-nv]

right... the naming is probably not perfect. I think we can update it.

[aristarkhovNV]

CLI helpers being optional ideally should not bloat the launcher api to keep it focused on its one core function. Keeping CLI helpers separate from the core launcher class would keep the door open for adding more such helpers in the future based on different arg parsers, env vars, etc.

patterm be like:

ArgParseLaunchHelper.register(parser)
with ArgParseLaunchHelper(parser): # optionally creates the launcher within the helper context
    ...