Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#5,072 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Bastante claro
Estado de actividad
Estancado
Stack tecnológico
node.js, python, typescript
Área
backend, build-system, devtools

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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

Lenguaje dominante
Python
Estrellas
6.2k
Forks
596
Merge medio
7 h 47 min
PR fusionados (30 d)
904

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de loopx-project/loopx

Todos los issues de loopx-project/loopx

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.