Consolidate discovery module ownership and split JSONRPC orchestration responsibilities
还没有人认领这个 Issue。
评估
调研方向
Start with the binary module declarations in crates/pet/src/main.rs, the public modules in crates/pet/src/lib.rs, and the orchestration in crates/pet/src/jsonrpc.rs. Review the landing order in #528 and dependencies #536, #539, and #540 before separating responsibilities. Done means behavior, ordering, state-sync semantics, coverage, documentation, formatting, tests, and warnings-as-errors checks remain intact.
由索引模型根据 Issue 内容生成。
描述
Tracking plan: #528
Priority: P3. Evidence: source-confirmed maintainability and duplicate-compilation concern; no runtime speedup is assumed.
Problem
The JSONRPC orchestration module combines handlers, configuration publication/rollback, refresh coordination, locator state transfer, and telemetry follow-up. The binary also declares find/locators modules that are already public modules in the library, creating parallel module instances instead of using one implementation boundary.
Sources: binary module declarations, library modules, JSONRPC orchestration.
Scope
Use the library discovery/locator implementation from both CLI and server entry points. Extract configuration publication and refresh coordination into independently testable components, leaving RPC handlers as thin adapters. Keep locator crates and priority ordering; avoid a workspace-wide crate merger or async rewrite.
Separate behavior changes from code movement so reviewers can verify this is behavior-preserving. Update architecture/state documentation to the final ownership model, including actual transient-versus-persistent cache lifetimes and all current locators such as Hatch. Move tests with their responsibilities without losing coverage or weakening assertions.
Acceptance criteria
- Binary and library no longer compile separate find/locators module instances; public interfaces remain deliberate and minimal.
- Configuration publication, refresh coordination, and handler adaptation have distinct, directly testable responsibilities.
- Existing CLI/JSONRPC output, error behavior, locator order, coalescing, generation checks, and state-sync semantics remain unchanged.
- Full default-feature tests, relevant feature/platform jobs, formatting, and warnings-as-errors lint pass.
- #531/#533 performance and #534 production coverage do not regress; no unmeasured runtime-speedup claim is used to justify the refactor.
- Documentation reflects the implementation and the change does not introduce generic abstractions used only once.
Dependencies
Perform after #536, bounded scheduling #539, and output ownership #540 stabilize; the complete landing order is in #528. Use #534 coverage and #531/#533 measurements as guardrails. Smaller purely mechanical library-module reuse can be split out earlier if isolated and separately reviewed.
- 主要语言
- Rust
- 星标
- 207
- 派生
- 45
- 平均合并
- 3 天 12 小时
- 30 天内合并 PR
- 11
贡献指南
这个仓库没有索引到贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
microsoft/python-environment-tools 的其他 Issue
-
enhancement
难度 5/5 一周以上 新手友好度 35/100
-
enhancement
难度 5/5 一周以上 新手友好度 35/100
-
debt
难度 5/5 一周以上 新手友好度 35/100
-
enhancement
难度 5/5 一周以上 新手友好度 35/100
microsoft/python-environment-tools#533 · 1 条评论 ·
-
debt
难度 5/5 一周以上 新手友好度 35/100
microsoft/python-environment-tools#534 · 1 条评论 ·
查看 microsoft/python-environment-tools 的全部 Issue
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 75/100
-
state:needs triage
难度 2/5 1-3 小时 新手友好度 70/100
zed-industries/zed#64680 · 2 条评论 ·
-
难度 2/5 1-3 小时 新手友好度 70/100
-
难度 2/5 1-3 小时 新手友好度 70/100
RustPython/RustPython#8802 ·
-
难度 2/5 1-3 小时 新手友好度 75/100
TheLarkInn/aipm#2390 ·