orch-cli 0.1.0__tar.gz → 0.1.1__tar.gz

{orch_cli-0.1.0 → orch_cli-0.1.1}/.gitignore

@@ -115,6 +115,8 @@ venv/
 ENV/
 env.bak/
 venv.bak/
+venv-*/
+venv-mock/
 
 # Spyder project settings
 .spyderproject

{orch_cli-0.1.0 → orch_cli-0.1.1}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: orch-cli
-Version: 0.1.0
+Version: 0.1.1
 Summary: A local development process orchestrator and venv-aware runner
 License: MIT
 License-File: LICENSE
@@ -15,7 +15,7 @@ Description-Content-Type: text/markdown
 
 [![PyPI version](https://img.shields.io/pypi/v/orch-cli.svg)](https://pypi.org/project/orch-cli/)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
-[![Build Status](https://github.com/EASYLIFECODE/orch/workflows/CI/badge.svg)](https://github.com/EASYLIFECODE/orch/actions)
+[![Build Status](https://github.com/EASYLIFECODE/orch-cli/workflows/CI/badge.svg)](https://github.com/EASYLIFECODE/orch-cli/actions)
 
 **Orch** is a lightweight, **daemon-less** command-line interface (CLI) tool designed to simplify local development of client-server or multi-service architectures. 
 
@@ -47,8 +47,8 @@ pip install orch-cli
 
 1. Clone the repository:
    ```bash
-   git clone https://github.com/EASYLIFECODE/orch.git
-   cd orch
+   git clone https://github.com/EASYLIFECODE/orch-cli.git
+   cd orch-cli
    ```
 
 2. Install in editable development mode:

{orch_cli-0.1.0 → orch_cli-0.1.1}/README.md

@@ -2,7 +2,7 @@
 
 [![PyPI version](https://img.shields.io/pypi/v/orch-cli.svg)](https://pypi.org/project/orch-cli/)
 [![License: MIT](https://img.shields.io/badge/License-MIT-yellow.svg)](https://opensource.org/licenses/MIT)
-[![Build Status](https://github.com/EASYLIFECODE/orch/workflows/CI/badge.svg)](https://github.com/EASYLIFECODE/orch/actions)
+[![Build Status](https://github.com/EASYLIFECODE/orch-cli/workflows/CI/badge.svg)](https://github.com/EASYLIFECODE/orch-cli/actions)
 
 **Orch** is a lightweight, **daemon-less** command-line interface (CLI) tool designed to simplify local development of client-server or multi-service architectures. 
 
@@ -34,8 +34,8 @@ pip install orch-cli
 
 1. Clone the repository:
    ```bash
-   git clone https://github.com/EASYLIFECODE/orch.git
-   cd orch
+   git clone https://github.com/EASYLIFECODE/orch-cli.git
+   cd orch-cli
    ```
 
 2. Install in editable development mode:

orch_cli-0.1.1/docs/SUMMARY-EN.md

@@ -0,0 +1,107 @@
+# Project Summary: CLI Local Orchestrator (`orch`)
+
+This document contains a comprehensive summary of the discussions, design decisions, internal architecture, commands, and workflows of **`orch`**, the local orchestration CLI tool designed for developers.
+
+---
+
+## 1. Purpose and Context
+`orch` is a lightweight terminal tool designed to orchestrate the execution of multiple local services (backends, frontends, agents, watchers) under a client-server architecture, without requiring containerization (like Docker) or persistent background daemon services.
+
+### Problems it solves:
+* **Multiple terminals**: Avoids having to open multiple PowerShell, CMD, or Bash windows for a single project.
+* **Virtualenv activation**: Automatically and transparently activates the Python virtual environment (`venv`) corresponding to the project.
+* **Centralized logs**: Unifies the outputs of all processes in real-time with colored, readable prefixes.
+* **Background persistence**: Allows running decoupled services in the background of the operating system, freeing up the current console.
+
+---
+
+## 2. Configuration Model (`orch.yml`)
+The project behavior is defined through a minimalist YAML configuration file located at the project root.
+
+```yaml
+project: Windows_Monitor
+
+# Global environment configuration
+env:
+  type: venv
+  path: ./venv-wind_monitor
+  variables:
+    GLOBAL_TEST_VAR: "orch-is-working"
+
+services:
+  backend:
+    path: ./backend
+    command: python app.py
+    env:
+      BACKEND_PORT: "8000"
+
+  ui:
+    path: ./ui
+    command: npm run dev
+
+  agent:
+    path: ./agent
+    command: python agent.py
+```
+
+---
+
+## 3. Commands and User Experience (UX)
+The project lifecycle is managed through two main workflows:
+
+### Workflow A: Active & Interactive Development (Foreground)
+* **Command**: `orch up`
+* **Behavior**: Starts all services sequentially in the current console. Multiplexes the text outputs of all processes in real-time using individual background threads.
+* **Termination**: When pressing `Ctrl+C`, `orch` intercepts the signal and cleanly and recursively terminates all created processes (including Node/Vite sub-processes).
+
+### Workflow B: Background Execution (Background / Detached)
+* **Start**: `orch start`  
+  Spawns sub-processes completely decoupled from the current terminal, silently redirecting their output to `.log` files in `.orch/logs/` and releasing the terminal immediately.
+* **Monitor**: `orch status`  
+  Queries the local state database and checks the operating system to see if the services are still active, showing a resource table:
+  ```text
+             Project: Windows_Monitor (Services Status)
+  ┌─────────┬─────────┬───────┬───────┬─────────────┬──────────┐
+  │ Service │ Status  │  PID  │ CPU % │ Memory (MB) │  Uptime  │
+  ├─────────┼─────────┼───────┼───────┼─────────────┼──────────┐
+  │ backend │ RUNNING │ 33284 │  0.0% │    162.1 MB │ 00:00:06 │
+  │ ui      │ RUNNING │ 16984 │  0.0% │    178.2 MB │ 00:00:06 │
+  │ agent   │ RUNNING │ 20392 │  0.0% │     56.7 MB │ 00:00:06 │
+  └─────────┴─────────┴───────┴───────┴─────────────┴──────────┘
+  ```
+* **Check Logs**: `orch logs` / `orch logs -f`  
+  Allows reading the last log lines or following them in real-time (multiplexing the queue of multiple log files at once).
+* **Stop**: `orch stop`  
+  Sends termination OS signals to all background services and cleans up their state registry.
+* **Clean**: `orch clean`  
+  Stops active services, truncates all log files in the `.orch/logs/` folder to 0 bytes, and resets the state database.
+
+---
+
+## 4. Internal Architecture (Daemon-less)
+
+The design of `orch` stands out for being lightweight and reliable thanks to the following technical solutions:
+
+### Dynamic Virtual Environment Activation (`venv`)
+`orch` does not execute traditional activation scripts (like `activate.bat` or `activate.sh`). Instead, it calculates the absolute path of the `venv` executables (e.g., `venv/Scripts` on Windows or `venv/bin` on Linux) and **injects it at the beginning of the `PATH` environment variable** of the sub-process. Thus, when the command calls `python`, the operating system naturally and automatically resolves and uses the Python executable from the virtual environment.
+
+### Multiplatform Background Persistency (Windows / Linux)
+To ensure processes survive the closing of the developer's terminal independently without requiring a persistent daemon running in the background:
+* **On Windows**: Spawns sub-processes in a decoupled manner using native Windows API flags in `subprocess.Popen`:
+  - `CREATE_NEW_CONSOLE (0x00000010)`: Assigns an exclusive console to prevent the process from depending on the parent console.
+  - `CREATE_NO_WINDOW (0x08000000)`: Hides the new console to prevent pop-up windows from bothering the user.
+  - `CREATE_BREAKAWAY_FROM_JOB (0x01000000)`: Allows the sub-process to escape the limits of the job group of the calling task.
+* **On Linux/macOS**: Uses `start_new_session=True` to decouple the process from the current terminal session.
+* Redirects standard input to `/dev/null` (`DEVNULL`) and diagnostics outputs directly to local log files.
+
+### Recycled PID Conflict Prevention
+The `.orch/state.json` file records not only the PID number but also the exact operating system process creation timestamp (`create_time` using the `psutil` library). When running control commands like `status` or `stop`, the current OS process PID is compared with this creation timestamp. If the PID was reassigned to a completely different program after the service closed, `orch` detects it instantly and avoids sending kill signals to the wrong system processes.
+
+### State Management
+The state of each service passes through one of the following stages:
+* **`RUNNING`**: The process was started, its PID exists and matches in the system.
+* **`CRASHED`**: The process finished unexpectedly (its PID does not exist in the system, but the user did not run a `stop` command).
+* **`STOPPED`**: The process was terminated intentionally through a stop command (`stop` / `clean`).
+
+### Terminal Output Escaping (Rich Markup)
+To prevent terminal outputs from common tools like Vite or Flask (which usually use square brackets and ANSI color codes) from interfering with the formatting engine of `Rich`, all log messages are processed using the `rich.markup.escape()` function. Additionally, the square brackets of the prefixes are protected with escape characters (`\\[`), allowing the colored format of service names to render correctly in any development terminal.

orch_cli-0.1.1/orch/__init__.py

@@ -0,0 +1 @@
+__version__ = "0.1.1"

{orch_cli-0.1.0 → orch_cli-0.1.1}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "hatchling.build"
 
 [project]
 name = "orch-cli"
-version = "0.1.0"
+version = "0.1.1"
 description = "A local development process orchestrator and venv-aware runner"
 readme = "README.md"
 requires-python = ">=3.8"

{orch_cli-0.1.0 → orch_cli-0.1.1}/test-project/orch.yml

@@ -2,6 +2,8 @@ project: test-project
 
 env:
   type: venv
+  # Note: ./venv-mock is ignored by git. 
+  # To test local venv injection, create it first using: python -m venv venv-mock
   path: ./venv-mock
   variables:
     GLOBAL_TEST_VAR: "orch-is-working"

orch_cli-0.1.0/cli_orchestrator_design.md

@@ -1,247 +0,0 @@
-# Propuesta de Diseño: CLI Local Orchestrator (`orch`)
-
-Esta propuesta de diseño detalla la arquitectura, el stack tecnológico y el flujo de experiencia de usuario (UX) para **`orch`**, una herramienta de terminal (CLI) diseñada para simplificar el desarrollo local de arquitecturas cliente-servidor y multiservicio sin la sobrecarga de contenedores (Docker).
-
----
-
-## 1. Arquitectura Interna
-
-Para mantener la herramienta ligera, predecible y fácil de instalar, se propone un diseño **sin demonios (daemonless)**. En lugar de un proceso en segundo plano persistente, la CLI utiliza el sistema de archivos local (`.orch/`) para guardar el estado y orquestar los procesos.
-
-```mermaid
-graph TD
-    CLI[CLI Command / orch] --> Config[Configuration Loader]
-    Config --> Validate[YAML Schema Validator]
-    Validate --> Run[Execution Engine]
-    
-    subgraph "Execution & Management"
-        Run --> PM[Process Manager]
-        PM --> Env[Environment Injector venv/node]
-        PM --> ProcTree[Child Process Tree]
-    end
-    
-    subgraph "State & Output"
-        ProcTree --> LogRouter[Log Router]
-        LogRouter --> Console[Console Output foreground]
-        LogRouter --> LogFile[Log Files .orch/logs/]
-        PM --> StateFile[State Registry .orch/state.json]
-    end
-```
-
-### Componentes Core:
-1. **CLI Parser (Interfaz de Usuario)**: Define la gramática de comandos (`up`, `start`, `stop`, `status`, `logs`, `restart`).
-2. **Configuration Loader & Environment Injector**:
-   - Detecta y valida el archivo `orch.yml` en la raíz del proyecto.
-   - Si se define un entorno virtual (`venv`), calcula la ruta absoluta del ejecutable de Python (p. ej., `venv/Scripts/python.exe` en Windows o `venv/bin/python` en Unix/Linux) e inyecta la carpeta del venv al inicio del `PATH` del subproceso.
-3. **Process Manager (Multiplataforma)**:
-   - Lanza los subprocesos de forma no bloqueante utilizando APIs del sistema operativo.
-   - En Windows, arranca los procesos con banderas específicas (como `CREATE_NEW_PROCESS_GROUP`) para asegurar que podamos detenerlos limpiamente a ellos y a sus subprocesos hijos.
-   - Mantiene un registro de los PIDs activos en `.orch/state.json`.
-4. **Log Router (Enrutador de Logs)**:
-   - Redirige `stdout` y `stderr` de cada servicio.
-   - **Modo Foreground (`orch up`)**: Intercala logs en tiempo real prefijándolos con el nombre del servicio en colores y enviándolos a la consola.
-   - **Modo Background (`orch start`)**: Escribe la salida en archivos separados en `.orch/logs/<servicio>.log`.
-5. **State Registry (`.orch/state.json`)**:
-   - Guarda metadatos sobre los procesos en ejecución: PID, comando, fecha de inicio y estado. Esto permite que comandos como `orch stop` o `orch status` consulten qué procesos están activos sin necesitar un servicio en segundo plano corriendo continuamente.
-
----
-
-## 2. Stack Tecnológico Recomendado
-
-Considerando que el desarrollador trabaja principalmente con **Python** y **Node.js**, existen tres stacks viables. Recomendamos **Python** o **Node.js** para facilitar la extensibilidad por parte del propio usuario.
-
-| Criterio | Opción A: Python (Recomendada) | Opción B: Node.js (TypeScript) | Opción C: Rust / Go |
-| :--- | :--- | :--- | :--- |
-| **Tecnología** | Python 3.8+ + `typer` + `rich` | Node.js + `commander` + `execa` | Rust + `clap` + `tokio` |
-| **Binario único** | No (requiere Python instalado) | No (requiere Node/npm) | **Sí** (Binario compilado nativo) |
-| **Gestión de Streams** | Buena | **Excelente** (Async por naturaleza) | Excelente |
-| **Manejo de Windows** | Excelente (con `psutil`) | Bueno (con `tree-kill`) | Complejo pero muy eficiente |
-| **Curva de desarrollo** | **Muy baja** (Fácil de modificar) | Baja | Alta |
-
-### Detalle del Stack Recomendado (Python):
-- **CLI Framework**: [Typer](https://typer.tiangolo.com/) (rápido, basado en anotaciones de tipo) o [Click](https://click.palletsprojects.com/).
-- **Visualización de Terminal**: [Rich](https://rich.readthedocs.io/) (para crear tablas de estado hermosas, colores consistentes en logs y spinners).
-- **Procesamiento y Control**: [psutil](https://github.com/giampaolo/psutil) (indispensable para matar árboles de procesos de forma cross-platform en Windows y Linux).
-- **Serialización**: `PyYAML` o `ruamel.yaml` para leer configuraciones YAML.
-
----
-
-## 3. Estructura del Archivo de Configuración (`orch.yml`)
-
-El archivo se estructurará de manera que sea minimalista pero extensible. Soportará variables de entorno comunes a todos los servicios y configuraciones de venv autodetectadas.
-
-```yaml
-# orch.yml
-project: control-house
-
-# Configuración global del entorno
-env:
-  type: venv
-  path: ./venv-control-house
-  variables:
-    DEBUG: "true"
-    DATABASE_URL: "sqlite:///./db.sqlite3"
-
-services:
-  backend:
-    path: ./backend
-    # La CLI detecta que es python y usa automáticamente el venv configurado globalmente
-    command: python app.py
-    env:
-      PORT: 8000
-
-  ui:
-    path: ./ui
-    # Para Node, hereda las variables del sistema y las globales
-    command: npm run dev
-    env:
-      VITE_API_URL: "http://localhost:8000"
-
-  agent:
-    path: ./agent
-    command: python agent.py
-    # Opción para reiniciar automáticamente si falla
-    restart: on-failure
-```
-
----
-
-## 4. Experiencia de Usuario (UX) e Interfaz CLI
-
-El flujo de trabajo se divide en dos paradigmas: ejecución interactiva (foreground) y ejecución en segundo plano (background).
-
-### Comandos Principales
-
-#### 1. Ejecución Interactiva (Estilo `docker-compose up`)
-Muestra los logs de todos los servicios intercalados en tiempo real en la consola activa. Al presionar `Ctrl+C` se detienen todos los servicios de forma segura.
-
-```bash
-$ orch up
-```
-*Visualización conceptual:*
-```text
-[backend]  INFO:     Started server process [12452]
-[ui]       VITE v5.2.11  ready in 254 ms
-[agent]    Connecting to broker...
-[backend]  GET /api/status - 200 OK
-[agent]    Broker connected. Listening to events...
-^C
-Stopping services...
-[backend]  Stopped (PID 12452)
-[ui]       Stopped (PID 12459)
-[agent]    Stopped (PID 12461)
-Orch: All services terminated cleanly.
-```
-
-#### 2. Ejecución en Segundo Plano (Estilo daemon-less)
-Inicia los servicios de forma asíncrona, liberando la terminal de inmediato.
-
-```bash
-$ orch start
-```
-*Visualización conceptual:*
-```text
-✔ Starting control-house services...
-  ✔ backend [PID 12452] - Started
-  ✔ ui      [PID 12459] - Started
-  ✔ agent   [PID 12461] - Started
-Run `orch status` to check active processes or `orch logs -f` to tail logs.
-```
-
-#### 3. Verificación de Estado
-Consulta el archivo `.orch/state.json` y valida si los PIDs siguen activos en el sistema operativo.
-
-```bash
-$ orch status
-```
-*Visualización conceptual:*
-```text
-Project: control-house
-Status: Running (3/3 services active)
-
- SERVICE   STATUS    PID     CPU     MEM       UPTIME    
- backend   RUNNING   12452   0.2%    45 MB     00:12:30  
- ui        RUNNING   12459   0.0%    82 MB     00:12:30  
- agent     RUNNING   12461   1.5%    32 MB     00:12:28  
-```
-
-#### 4. Consulta de Logs en Segundo Plano
-Muestra los logs guardados en archivo con opción de seguimiento en tiempo real (`-f`).
-
-```bash
-$ orch logs backend -f
-# O para ver todos a la vez:
-$ orch logs -f
-```
-
-#### 5. Detención de Servicios
-Lee `.orch/state.json`, envía señales de terminación a los PIDs registrados (y a sus hijos) y limpia el estado.
-
-```bash
-$ orch stop
-```
-
----
-
-## 5. Comparativa con Alternativas Existentes
-
-| Herramienta | venv Automático | Windows Nativo | Modo Background Integrado | Fácil de Extender (YAML) |
-| :--- | :--- | :--- | :--- | :--- |
-| **`orch` (Propuesta)** | **Sí** (Inyección transparente) | **Sí** (Manejo robusto con psutil) | **Sí** (Vía registro PID local) | **Sí** (Configuración YAML simple) |
-| **PM2** | No (Requiere scripts wrappers) | Parcial (Problemas con bash/cmd) | Sí (Tiene daemon propio) | No (JS/JSON, complejo para Python) |
-| **Foreman / Honcho** | Parcial (Honcho lo soporta a medias)| Regular (Soporte Windows limitado) | No (Principalmente foreground) | No (Usa formato Procfile plano) |
-| **Docker Compose** | No aplica | Sí (Vía WSL2/HyperV) | Sí | Sí |
-
-> [!NOTE]
-> La principal ventaja de **`orch`** frente a PM2 o Foreman es su alineación exacta con el ecosistema de Python y Node local. Al inyectar el entorno virtual de forma transparente en el `PATH` de ejecución, evita la necesidad de configurar scripts de activación (`activate.bat` o `activate.sh`) en cada comando de servicio.
-
----
-
-## 6. Roadmap de Evolución (Sin Sobreingeniería)
-
-Para lograr una entrega iterativa y evitar la parálisis por análisis, sugerimos estructurar el desarrollo en 4 fases rápidas:
-
-```mermaid
-gantt
-    title Roadmap de Desarrollo orch
-    dateFormat  YYYY-MM-DD
-    section Fase 1: Core MVP
-    Core Execution (Foreground)      :active, f1, 2026-06-22, 5d
-    venv Ingestion                   :active, f1_venv, after f1, 3d
-    section Fase 2: Background Ops
-    State File Management (.orch)    : f2_state, after f1_venv, 4d
-    start/stop/status commands      : f2_cmds, after f2_state, 4d
-    section Fase 3: UX & TUI
-    Rich Logs Formatting             : f3_logs, after f2_cmds, 3d
-    Interactive Dashboard (TUI)      : f3_dashboard, after f3_logs, 5d
-    section Fase 4: Control Avanzado
-    Dependency Checks (ports)        : f4, after f3_dashboard, 4d
-```
-
-### Fase 1: Core MVP (Visualización Interactiva en Primer Plano)
-* **Objetivo**: Poder ejecutar `orch up` y ver todos los servicios corriendo, respetando el entorno virtual de Python.
-* **Entregables**:
-  - Lector del archivo `orch.yml`.
-  - Inyector de variables de entorno y venv.
-  - Ejecutor concurrente de hilos de lectura para `stdout`/`stderr`.
-  - Manejador de señal `SIGINT` (Ctrl+C) que mate todos los procesos activos usando `psutil`.
-
-### Fase 2: Ejecución en Segundo Plano (Daemon-less)
-* **Objetivo**: Permitir desvincular los procesos de la terminal actual escribiendo el estado en un registro local.
-* **Entregables**:
-  - Creación de la carpeta oculta `.orch/` en la raíz del proyecto.
-  - Implementación del comando `start`: arranca procesos de forma desvinculada (detached) y guarda los PIDs en `.orch/state.json`.
-  - Redirección de logs a `.orch/logs/<service>.log`.
-  - Comandos `status` (chequea si los PIDs viven), `logs` (lectura estática o tailing con `tail -f` simulado), y `stop` (envía señal de muerte a los PIDs).
-
-### Fase 3: UX Avanzada & Dashboard Interactivo (TUI)
-* **Objetivo**: Darle un aspecto profesional con reportes tabulares y un panel de control interactivo simple.
-* **Entregables**:
-  - Formateo de logs con marcas de tiempo y colores consistentes usando la librería `rich`.
-  - Pantalla interactiva opcional `orch dashboard` que muestre el estado de los recursos de forma dinámica utilizando `Textual` (TUI de Python).
-
-### Fase 4: Control de Dependencias y Healthchecks
-* **Objetivo**: Evitar errores de conexión esperando a que un servicio esté listo antes de arrancar el siguiente.
-* **Entregables**:
-  - Propiedad `depends_on` en la configuración (p. ej., `ui` depende de `backend`).
-  - Verificaciones de puertos locales: si el backend levanta en el puerto 8000, la CLI espera a que ese puerto esté abierto antes de iniciar el comando del frontend.

orch_cli-0.1.0/implementation_plan.md

@@ -1,99 +0,0 @@
-# Plan de Implementación: CLI Local Orchestrator (`orch`)
-
-Este documento describe el plan para desarrollar la herramienta CLI `orch` en Python utilizando un enfoque daemonless con archivos de estado locales.
-
----
-
-## 1. Stack de Desarrollo y Dependencias
-
-El proyecto se estructurará como un paquete instalable de Python usando `pyproject.toml` para que pueda registrarse como un comando global (`orch`) en el sistema del usuario.
-
-### Dependencias Principales:
-* **`typer[all]`**: Framework moderno para crear la CLI.
-* **`pyyaml`**: Lector de configuración `orch.yml`.
-* **`psutil`**: Gestión multiplataforma de PIDs, monitoreo de CPU/memoria y eliminación de árboles de subprocesos.
-* **`rich`**: Formateo estético de tablas, logs en color y visualización de estados en consola.
-
----
-
-## 2. Estructura del Código Propuesta
-
-Crearemos el proyecto en la carpeta raíz del workspace:
-
-```text
-EASYLIFECODE/
-├── pyproject.toml         # Configuración del paquete y dependencias
-├── README.md              # Documentación básica
-├── orch/
-│   ├── __init__.py
-│   ├── cli.py             # Definición de comandos Typer (up, start, stop, etc.)
-│   ├── config.py          # Lector y validador de config (orch.yml)
-│   ├── manager.py         # Orquestador de procesos (foreground/background)
-│   └── state.py           # Gestor de base de datos local (.orch/state.json)
-```
-
----
-
-## 3. Cambios Propuestos por Archivo
-
-### [NEW] [pyproject.toml](file:///c:/Users/antma.4M12-PC/OneDrive/Desktop/EASYLIFECODE/pyproject.toml)
-Configuración del proyecto con Hatchling como backend de empaquetado, dependencias y registro del script de consola `orch`.
-
-### [NEW] [config.py](file:///c:/Users/antma.4M12-PC/OneDrive/Desktop/EASYLIFECODE/orch/config.py)
-* Carga del archivo `orch.yml`.
-* Resolución de rutas relativas basadas en la ubicación de `orch.yml`.
-* Detección y activación del entorno virtual de Python:
-  - En Windows: añade `path/to/venv/Scripts` al inicio de `PATH` y define `VIRTUAL_ENV`.
-  - En Linux/macOS: añade `path/to/venv/bin` al inicio de `PATH` y define `VIRTUAL_ENV`.
-
-### [NEW] [state.py](file:///c:/Users/antma.4M12-PC/OneDrive/Desktop/EASYLIFECODE/orch/state.py)
-* Creación y lectura de la carpeta `.orch/`.
-* Serialización del estado de procesos activos en `.orch/state.json` (estructura JSON con PID, hora de inicio, nombre del servicio, ruta de logs).
-* Verificación en tiempo real si los PIDs registrados siguen activos en el sistema operativo usando `psutil`.
-
-### [NEW] [manager.py](file:///c:/Users/antma.4M12-PC/OneDrive/Desktop/EASYLIFECODE/orch/manager.py)
-* **`run_foreground`**:
-  - Inicia todos los servicios secuencialmente.
-  - Captura `stdout`/`stderr` de manera asíncrona usando hilos (`threading.Thread`) o colas para evitar bloqueos.
-  - Asigna un color único de `rich` a cada servicio para imprimir los logs de forma intercalada y legible.
-  - Escucha la señal `SIGINT` (Ctrl+C) y detiene todos los procesos creados y sus procesos hijos.
-* **`run_background`**:
-  - Arranca procesos desacoplados (`subprocess.Popen` con banderas para crear un nuevo grupo de procesos).
-  - Redirige la salida a archivos `.orch/logs/<service>.log`.
-  - Registra los PIDs en `state.py`.
-* **`stop_services`**:
-  - Lee el estado, localiza los PIDs activos y utiliza `psutil.Process(pid).terminate()` o `.kill()` en cascada sobre los hijos del proceso (útil para comandos que abren otros subprocesos como `npm run dev`).
-
-### [NEW] [cli.py](file:///c:/Users/antma.4M12-PC/OneDrive/Desktop/EASYLIFECODE/orch/cli.py)
-Entrada principal de la CLI con los siguientes subcomandos:
-* `up`: Levanta todos los servicios en primer plano.
-* `start`: Levanta todos los servicios en segundo plano.
-* `stop`: Detiene todos los servicios en segundo plano.
-* `status`: Muestra el estado actual y estadísticas de recursos (CPU, Memoria) de los procesos activos.
-* `logs [service] [-f/--follow]`: Muestra logs locales e implementa tailing en tiempo real.
-* `restart [service]`: Detiene y vuelve a iniciar uno o todos los servicios.
-
----
-
-## 4. Plan de Verificación
-
-### Pruebas Automatizadas
-* Validaremos la sintaxis del CLI invocando comandos de ayuda.
-* Comprobaremos que el paquete se puede instalar localmente en modo desarrollo:
-  ```bash
-  pip install -e .
-  ```
-
-### Verificación Manual (Escenario de prueba)
-Crearemos un proyecto ficticio de prueba dentro de `EASYLIFECODE/test-project/` con:
-* Un backend mock en Python (`app.py` que imprima logs periódicamente).
-* Un frontend mock en Node (`package.json` con un script mock).
-* Un entorno virtual de Python (`venv`).
-* Archivo `orch.yml`.
-
-Verificaremos:
-1. `orch up` funciona, intercala logs y detiene todo con `Ctrl+C`.
-2. `orch start` inicia los servicios silenciosamente.
-3. `orch status` muestra los servicios activos con sus respectivos PIDs y consumo de memoria/CPU.
-4. `orch logs -f` muestra la salida unificada.
-5. `orch stop` limpia el estado y termina todos los procesos.

orch_cli-0.1.0/orch/__init__.py

@@ -1 +0,0 @@
-__version__ = "0.1.0"

orch_cli-0.1.0/task.md

@@ -1,8 +0,0 @@
-# Tareas: Implementación de la CLI `orch`
-
-- `[x]` Crear la estructura del proyecto y `pyproject.toml`
-- `[x]` Implementar el cargador de configuración (`orch/config.py`)
-- `[x]` Implementar el gestor de estado local (`orch/state.py`)
-- `[x]` Implementar el gestor de procesos (`orch/manager.py`)
-- `[x]` Implementar la interfaz CLI con Typer (`orch/cli.py`)
-- `[x]` Crear un proyecto de prueba y verificar el funcionamiento

orch_cli-0.1.0/test-project/venv-mock/Lib/site-packages/pip/__init__.py

@@ -1,13 +0,0 @@
-from typing import List, Optional
-
-__version__ = "24.3.1"
-
-
-def main(args: Optional[List[str]] = None) -> int:
-    """This is an internal API only meant for use by pip's own console scripts.
-
-    For additional details, see https://github.com/pypa/pip/issues/7498.
-    """
-    from pip._internal.utils.entrypoints import _wrapper
-
-    return _wrapper(args)

orch_cli-0.1.0/test-project/venv-mock/Lib/site-packages/pip/__main__.py

@@ -1,24 +0,0 @@
-import os
-import sys
-
-# Remove '' and current working directory from the first entry
-# of sys.path, if present to avoid using current directory
-# in pip commands check, freeze, install, list and show,
-# when invoked as python -m pip <command>
-if sys.path[0] in ("", os.getcwd()):
-    sys.path.pop(0)
-
-# If we are running from a wheel, add the wheel to sys.path
-# This allows the usage python pip-*.whl/pip install pip-*.whl
-if __package__ == "":
-    # __file__ is pip-*.whl/pip/__main__.py
-    # first dirname call strips of '/__main__.py', second strips off '/pip'
-    # Resulting path is the name of the wheel itself
-    # Add that to sys.path so we can import pip
-    path = os.path.dirname(os.path.dirname(__file__))
-    sys.path.insert(0, path)
-
-if __name__ == "__main__":
-    from pip._internal.cli.main import main as _main
-
-    sys.exit(_main())

orch_cli-0.1.0/test-project/venv-mock/Lib/site-packages/pip/__pip-runner__.py

@@ -1,50 +0,0 @@
-"""Execute exactly this copy of pip, within a different environment.
-
-This file is named as it is, to ensure that this module can't be imported via
-an import statement.
-"""
-
-# /!\ This version compatibility check section must be Python 2 compatible. /!\
-
-import sys
-
-# Copied from pyproject.toml
-PYTHON_REQUIRES = (3, 8)
-
-
-def version_str(version):  # type: ignore
-    return ".".join(str(v) for v in version)
-
-
-if sys.version_info[:2] < PYTHON_REQUIRES:
-    raise SystemExit(
-        "This version of pip does not support python {} (requires >={}).".format(
-            version_str(sys.version_info[:2]), version_str(PYTHON_REQUIRES)
-        )
-    )
-
-# From here on, we can use Python 3 features, but the syntax must remain
-# Python 2 compatible.
-
-import runpy  # noqa: E402
-from importlib.machinery import PathFinder  # noqa: E402
-from os.path import dirname  # noqa: E402
-
-PIP_SOURCES_ROOT = dirname(dirname(__file__))
-
-
-class PipImportRedirectingFinder:
-    @classmethod
-    def find_spec(self, fullname, path=None, target=None):  # type: ignore
-        if fullname != "pip":
-            return None
-
-        spec = PathFinder.find_spec(fullname, [PIP_SOURCES_ROOT], target)
-        assert spec, (PIP_SOURCES_ROOT, fullname)
-        return spec
-
-
-sys.meta_path.insert(0, PipImportRedirectingFinder())
-
-assert __name__ == "__main__", "Cannot run __pip-runner__.py as a non-main module"
-runpy.run_module("pip", run_name="__main__", alter_sys=True)

orch_cli-0.1.0/test-project/venv-mock/Lib/site-packages/pip/_internal/__init__.py

@@ -1,18 +0,0 @@
-from typing import List, Optional
-
-from pip._internal.utils import _log
-
-# init_logging() must be called before any call to logging.getLogger()
-# which happens at import of most modules.
-_log.init_logging()
-
-
-def main(args: Optional[List[str]] = None) -> int:
-    """This is preserved for old console scripts that may still be referencing
-    it.
-
-    For additional details, see https://github.com/pypa/pip/issues/7498.
-    """
-    from pip._internal.utils.entrypoints import _wrapper
-
-    return _wrapper(args)