machinaos 0.0.81 → 0.0.82

package/client/package.json

@@ -1,7 +1,7 @@
 {
   "name": "react-flow-client",
   "private": true,
-  "version": "0.0.81",
+  "version": "0.0.82",
   "type": "module",
   "scripts": {
     "start": "vite --host 0.0.0.0",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "machinaos",
-  "version": "0.0.81",
+  "version": "0.0.82",
   "description": "Open source workflow automation platform with AI agents, React Flow, and n8n-inspired architecture",
   "type": "module",
   "keywords": [
@@ -53,6 +53,7 @@
     "!**/node_modules/",
     "!**/.vite/",
     ".env.template",
+    "pyproject.toml",
     "README.md",
     "install.sh",
     "install.ps1"

package/pyproject.toml

@@ -0,0 +1,57 @@
+[project]
+name = "machinaos-cli"
+version = "0.1.0"
+description = "MachinaOS project supervisor CLI (machina)."
+requires-python = ">=3.12"
+dependencies = [
+    "typer>=0.12",
+    "rich>=13",
+    "anyio>=4",
+    "psutil>=6",
+    # OS-native user data / cache / config / log dirs. Soft dependency
+    # in the CLI (``cli/platform_.py`` imports it inside a try/except
+    # and falls back to a stdlib implementation if the wheel isn't
+    # available) so ``machina clean`` / ``machina build`` still work
+    # immediately after a wipe, before ``pip install`` has had a
+    # chance to materialise it.
+    "platformdirs>=4.0",
+    # Required on Windows for the supervisor's Job Object (cli/tree.py).
+    # Without it, child processes survive abnormal supervisor exit
+    # (SIGKILL, BSOD, console close) and accumulate as orphans across
+    # dev restarts. Floor 308 is the first release shipping prebuilt
+    # wheels for Python 3.13.
+    "pywin32>=308; platform_system == 'Windows'",
+]
+
+[project.scripts]
+machina = "cli.cli:app"
+
+[build-system]
+requires = ["hatchling"]
+build-backend = "hatchling.build"
+
+[tool.hatch.build.targets.wheel]
+packages = ["cli"]
+
+# The CLI runs under the user's global / pipx-managed Python — it is
+# NOT a uv-managed project. ``managed = false`` tells ``uv`` to leave
+# this project alone: ``uv sync`` at the repo root is a no-op, no
+# ``<repo>/.venv/`` is created, ``python`` on PATH resolves to the
+# user's global interpreter instead of being shadowed by a workspace
+# venv. The server is the only uv-managed project (``server/.venv``).
+[tool.uv]
+managed = false
+
+[dependency-groups]
+dev = []
+
+# ``machinaos-cli`` is a standalone Python CLI package -- installable
+# via ``pipx install .`` / ``pip install .`` against any Python >=3.12
+# without involving uv. It depends on nothing from ``server/``. The
+# server has its own uv-managed venv at ``server/.venv``; the CLI
+# invokes server-side commands by shelling out via ``cli.run.uv_run``
+# (which runs ``uv run --no-sync ...`` with ``cwd=server/`` so uv
+# discovers ``server/pyproject.toml`` and activates ``server/.venv``).
+# Keeping the CLI independent of the uv workspace means contributors
+# can install / run / debug ``machina`` on whatever interpreter is on
+# PATH -- no per-checkout venv activation required.

package/scripts/install.js

@@ -23,12 +23,20 @@ const ROOT = resolve(__dirname, '..');
 process.env.PYTHONUTF8 = '1';
 
 function run(cmd, cwd = ROOT, timeoutMs = 300000) {
+  // Strip VIRTUAL_ENV from the spawned env. When the user runs
+  // ``npm install -g machinaos`` from a shell that has activated a
+  // venv (very common during dev), uv emits a noisy ``VIRTUAL_ENV
+  // ... does not match the project environment path`` warning per
+  // invocation. uv only honours VIRTUAL_ENV with ``--active``, which
+  // we never pass, so dropping it at the source is the documented
+  // workaround. Same fix applied to cli/supervisor.py's _full_env.
+  const { VIRTUAL_ENV, ...cleanEnv } = process.env;
   execSync(cmd, {
     cwd,
     stdio: 'inherit',
     shell: true,
     timeout: timeoutMs,
-    env: { ...process.env, MACHINAOS_INSTALLING: 'true' }
+    env: { ...cleanEnv, MACHINAOS_INSTALLING: 'true' }
   });
 }