Embed CloudXRLauncher lifecycle inside TeleopSession
维护者通常 1 天内回复
还没有人认领这个 Issue。
评估
调研方向
从 TeleopSession 和 CloudXRLauncher 入口点开始，检查现有 mcap 示例中嵌套的上下文管理器。跟踪启动、连接失败和 teardown 的顺序，然后添加覆盖，展示内部所有权、对外部 launcher 的 opt-out 以及失败时的干净清理；现有 mcap 示例必须仍然能够正常工作。
由索引模型根据 Issue 内容生成。
描述
Embed CloudXRLauncher lifecycle inside TeleopSession
Context
In the live teleop path, users currently have to set up the CloudXR runtime
launcher and the teleop session as two separate context managers:
```python
with launcher_ctx as launcher:
if launcher is not None:
print(f"[live] CloudXR runtime started (WSS log: {launcher.wss_log_path})")
print("[live] waiting for headset connection… (Ctrl+C to stop)")
with TeleopSession(config) as session:
...
```
This was raised in review on the mcap-example PR (@aristarkhovNV): the nested
launcher context is extra plumbing the caller shouldn't have to wire up by hand.
Deferring it out of that PR to keep its scope on the mcap example only.
Proposal
Have TeleopSession optionally own the CloudXRLauncher lifecycle so the
common case collapses to a single context manager:
python with TeleopSession(config) as session: ...
TeleopSession.__enter__ would start the launcher (when configured for the
live/CloudXR path) and __exit__ would tear it down, surfacing wss_log_path
and any launcher state via the session object.
Motivation
- Removes boilerplate and the nested
withfrom every caller. - Single ownership point for startup/teardown ordering (launcher must come up
before the session connects, and tear down after). - Centralizes the
launcher is not Noneguard instead of leaking it to callers.
Open questions / considerations
- Opt-out path: keep the ability to inject an externally-managed launcher
(e.g. passlauncher=...ormanage_launcher=False) for callers that need to
share one launcher across sessions or control its lifecycle themselves. - Backward compatibility: does anything depend on the current two-context
shape? If so, keep the standalone launcher context working. - Failure semantics: if the launcher starts but the session fails to
connect, ensure the launcher is cleanly torn down (no orphaned runtime). - Logging: preserve the
[live] CloudXR runtime started (WSS log: …)and
"waiting for headset connection" messages, moved inside the session.
Acceptance criteria
-
TeleopSessioncan start/stop the CloudXR launcher internally when configured. - Single
with TeleopSession(config)works for the live path. - An escape hatch exists for an externally-managed launcher.
- Startup/teardown ordering and failure cleanup are covered by a test.
- Existing mcap example still works.
- 主要语言
- Python
- 星标
- 403
- 派生
- 94
- 平均合并
- 2 天 5 小时
- 30 天内合并 PR
- 95
环境准备
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
NVIDIA/IsaacCapture 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 68/100
NVIDIA/IsaacCapture#910 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 88/100
NVIDIA/IsaacCapture#891 ·
维护者通常 1 天内回复
-
难度 4/5 3-5 天 新手友好度 25/100
NVIDIA/IsaacCapture#1217 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 20/100
NVIDIA/IsaacCapture#1214 · 1 条评论 ·
维护者通常 1 天内回复
-
难度 3/5 1-2 天 新手友好度 50/100
NVIDIA/IsaacCapture#1181 ·
维护者通常 1 天内回复
查看 NVIDIA/IsaacCapture 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 62/100
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
WingedGuardian/GENesis-AGI#3375 ·
维护者通常 1 天内回复
-
curriculum documentation quality
难度 2/5 1-3 小时 新手友好度 75/100
githubnext/gh-aw-workshop#4601 ·
维护者通常 1 天内回复
-
approved Good First Issue scope: docs
难度 1/5 1 小时以内 新手友好度 85/100
hiero-ledger/hiero-sdk-python#2730 · 3 条评论 ·
维护者通常 1 天内回复