|
| 1 | +# Migration Feature Parity with ComfyUI-Manager v4 |
| 2 | + |
| 3 | +## Current Implementation (Step 3) |
| 4 | + |
| 5 | +Our migration copies custom node directories and installs `requirements.txt` |
| 6 | +via `uv pip install`, filtering out PyTorch packages. This covers the basic |
| 7 | +case but misses several things Manager does. |
| 8 | + |
| 9 | +## What We're Missing |
| 10 | + |
| 11 | +### 1. `install.py` Execution (High Priority) |
| 12 | + |
| 13 | +Many custom nodes ship an `install.py` that runs arbitrary setup: downloading |
| 14 | +models, compiling C/CUDA extensions, creating config files, etc. Manager runs |
| 15 | +this **after** `requirements.txt` with `cwd` set to the node directory and two |
| 16 | +environment variables: |
| 17 | + |
| 18 | +- `COMFYUI_PATH` — path to the ComfyUI root |
| 19 | +- `COMFYUI_FOLDERS_BASE_PATH` — base path for ComfyUI folders |
| 20 | + |
| 21 | +### 2. pip Blacklist / Downgrade Protection (Medium Priority) |
| 22 | + |
| 23 | +Manager maintains: |
| 24 | + |
| 25 | +- **Blacklist** (never install): `torch`, `torchaudio`, `torchsde`, |
| 26 | + `torchvision` |
| 27 | +- **Downgrade blacklist** (never downgrade): `transformers`, `safetensors`, |
| 28 | + `kornia`, plus all of the above |
| 29 | + |
| 30 | +We currently only filter `torch`, `torchvision`, `torchaudio` from |
| 31 | +requirements. Missing `torchsde`. No downgrade protection. |
| 32 | + |
| 33 | +### 3. `--index-url` Parsing (Low Priority) |
| 34 | + |
| 35 | +Manager parses `--index-url` / `--extra-index-url` directives inline in |
| 36 | +`requirements.txt` and forwards them to pip. We currently pass the entire |
| 37 | +filtered file to `uv pip install` which may not handle these correctly. |
| 38 | + |
| 39 | +### 4. `pip_fixer.fix_broken()` (Low Priority) |
| 40 | + |
| 41 | +After installing requirements, Manager runs a broken-package repair pass. |
| 42 | +We don't do this. |
| 43 | + |
| 44 | +### 5. `pip_overrides.json` (Low Priority) |
| 45 | + |
| 46 | +Manager supports user-configured package name remapping. Not relevant for |
| 47 | +migration but worth noting for completeness. |
| 48 | + |
| 49 | +## Delegating to ComfyUI-Manager |
| 50 | + |
| 51 | +If Manager is installed in the **destination** installation, we can delegate |
| 52 | +the entire post-copy dependency process to it instead of doing it ourselves. |
| 53 | +This gets us full feature parity for free. |
| 54 | + |
| 55 | +### Option A: `cm-cli.py restore-dependencies` (Recommended) |
| 56 | + |
| 57 | +Run after copying node directories, before the user launches ComfyUI: |
| 58 | + |
| 59 | +``` |
| 60 | +python <ComfyUI>/custom_nodes/ComfyUI-Manager/cm-cli.py restore-dependencies |
| 61 | +``` |
| 62 | + |
| 63 | +- Iterates every non-disabled directory in `custom_nodes/` |
| 64 | +- Calls `execute_install_script` for each (requirements + install.py) |
| 65 | +- No running server needed, no knowledge of node IDs required |
| 66 | +- Works for all node types (git, CNR, unknown) |
| 67 | + |
| 68 | +### Option B: `cm-cli.py post-install <path>` |
| 69 | + |
| 70 | +For a single node: |
| 71 | + |
| 72 | +``` |
| 73 | +python <ComfyUI>/custom_nodes/ComfyUI-Manager/cm-cli.py post-install /path/to/node |
| 74 | +``` |
| 75 | + |
| 76 | +### Option C: Write `#LAZY-INSTALL-SCRIPT` entries |
| 77 | + |
| 78 | +Append entries to `<user_dir>/ComfyUI-Manager/startup-scripts/install-scripts.txt`: |
| 79 | + |
| 80 | +```python |
| 81 | +['/path/to/custom_nodes/MyNode', '#LAZY-INSTALL-SCRIPT', '/path/to/python'] |
| 82 | +``` |
| 83 | + |
| 84 | +Manager processes these on next boot, then auto-restarts ComfyUI. This is the |
| 85 | +deferred approach — no extra subprocess needed during migration, but deps |
| 86 | +aren't installed until next launch. |
| 87 | + |
| 88 | +### Detection |
| 89 | + |
| 90 | +Check if Manager is present: |
| 91 | + |
| 92 | +```javascript |
| 93 | +const managerCli = path.join(comfyUIDir, "custom_nodes", "ComfyUI-Manager", "cm-cli.py"); |
| 94 | +const hasManager = fs.existsSync(managerCli); |
| 95 | +``` |
| 96 | + |
| 97 | +### Hybrid Strategy |
| 98 | + |
| 99 | +1. Check if Manager exists in the destination installation |
| 100 | +2. If yes: use Option A (`restore-dependencies`) or Option C (lazy scripts) |
| 101 | + and skip our own `uv pip install` phase entirely |
| 102 | +3. If no: fall back to our current `uv pip install` approach (sans install.py) |
| 103 | + |
| 104 | +Option C (lazy scripts) is attractive because: |
| 105 | +- Zero extra time during migration |
| 106 | +- Manager handles everything on next boot including restart |
| 107 | +- Consistent with how Manager itself queues installs on Windows |
| 108 | + |
| 109 | +Option A is better when: |
| 110 | +- User wants deps ready before first launch |
| 111 | +- We want to show progress/output during migration |
| 112 | + |
| 113 | +## TODO |
| 114 | + |
| 115 | +- [x] Add `torchsde` to our PyTorch filter regex |
| 116 | +- [ ] Add `install.py` execution to our fallback (no-Manager) path |
| 117 | +- [ ] Detect Manager in destination and delegate when available |
| 118 | +- [ ] Add `--index-url` passthrough for requirements files |
0 commit comments