Hacktoberfest 2026:维护者为十月标记出来的 issue,仍然开放、适合新手。 浏览 Hacktoberfest issue

RFC: split LoopX distributions inside the monorepo (loopx-core / loopx-workspace / capability packages) and pin top-level module growth

未关闭
#5,072 2 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

维护者通常 1 天内回复

还没有人认领这个 Issue。

评估

难度
5/5
预计耗时
一周以上
新手友好度
25/100
Issue 类型
重构
描述清晰度
基本清楚
活跃度
停滞
技术栈
node.js, python, typescript

调研方向

Start by reading pyproject.toml and tests/architecture/test_control_plane_import_boundaries.py to understand the current packaging and architecture checks. The RFC PR is already linked, so check its discussion before taking on work. Done would mean the agreed distribution boundaries, compatibility period, and acceptance checks are implemented and verified.

由索引模型根据 Issue 内容生成。

描述

enhancement

Problem

The loopx wheel is one distribution that installs the kernel, the CLI, 33 built-in capabilities, the chat/workspace server, and the Python side of the TS effect runtime. On main@3e443ad7c:

  • loopx/ top level: 143 flat *.py files / ~78.8k lines, including 37 chat_*.py modules and 9 *_goal_mode/ host packages next to the kernel.
  • loopx/control_plane ≈131k lines, loopx/capabilities ≈115k lines, loopx/extensions ≈44k lines in one package.
  • pyproject.toml declares dependencies = [] and describes "a lightweight ... control plane", but the effect runtime requires Node.js ≥ 22.22.3 for every install, including CLI-only or kernel-only use.
  • Coupling is bidirectional: 52 kernel/CLI/top-level modules import loopx.capabilities; 74 capability modules import loopx.control_plane.
  • packages/ already hosts 9 independently packaged extensions (loopx-finance-*, loopx-jev, loopx-obelisk, loopx-repo-health, ...), so the repository has two packaging conventions at once.

Effects: first-use installs pull everything; contributors cannot find module boundaries from the tree; the import-boundary tests protect control_plane inward edges but nothing stops the top level from growing.

Proposal (monorepo stays; distributions split)

Do not split the repository. Keep one repo and one PR/CI flow, especially while the TypeScript control-plane migration is in its transaction-cutover phase. Instead:

  1. Top-level regrouping first (pure moves + compat re-exports): loopx/chat_*.py → loopx/chat/; loopx/*_goal_mode/ → loopx/hosts/; keep import paths working through re-export shims for at least one minor release.
  2. Architecture test "top-level file count does not grow": alongside tests/architecture/test_control_plane_import_boundaries.py, pin the current count of loopx/*.py and only allow it to decrease.
  3. Distributions: loopx-core (kernel + CLI + minimal host adapters; Node runtime declared as an optional extra or bundled), loopx-workspace (chat server, apps/presentation, desktop), and per-capability packages migrated into packages/ behind the existing CapabilityRegistry provider boundary.
  4. Package graduation to separate repos is explicitly out of scope until the kernel migration is complete and a package has its own maintainers.

Acceptance sketch

  • pip install loopx-core on a clean machine without Node succeeds and loopx --help / read-only status work; effect-runtime commands report a typed node_unavailable diagnostic instead of failing at import time.
  • loopx/*.py count is pinned and decreasing; the architecture test fails on any new top-level module.
  • Existing import loopx.chat_server style imports keep working for one minor release with a deprecation note.
  • Capability packages moved to packages/ install/uninstall independently and off-state preserves core behavior (same rule as existing extensions).

RFC PR: https://github.com/loopx-project/loopx/pull/5073

主要语言
Python
星标
6.2k
派生
596
平均合并
7 小时 47 分钟
30 天内合并 PR
904

环境准备

从这里开始

  1. 先读完整个 Issue,再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库,在一个分支上完成修改。
  4. 提交 Pull Request,并在描述里引用这个 Issue 编号。

loopx-project/loopx 的其他 Issue

查看 loopx-project/loopx 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。