Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#5,072 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
node.js, python, typescript
Ambito
backend, build-system, devtools

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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

Lingua principale
Python
Stelle
6.2k
Fork
596
Merge medio
7h 35m
PR unite (30g)
928

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di loopx-project/loopx

Tutte le issue di loopx-project/loopx

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.