ComfyUI Base 3.22.1: triton beside the testbed's CPU torch on Linux

[Soul-Craft]

Why

Found 2026-10-17 by SoulCraft-Org/image-creator-krea-2#10. The shared CPU testbed (testbed.sh --server) builds its venv with CPU torch on Linux (UV_TORCH_BACKEND=cpu, 3.18.2). CPU torch has no triton; a pod's CUDA torch carries it (lib/30-venv.sh keeps it in the torch family). Two packs import it at module level:

• ComfyUI-RMBG at its HEAD (229529e) bundles a sam3 copy whose models/sam3/model/edt.py does import triton. RMBG's loader (__init__.py, load_nodes) prints {module_name}, an undefined name, in its except branch. So one failing file becomes a NameError and the whole pack fails to register.
• ComfyUI-Easy-Sam3 stops on No module named 'triton'.

Every package that uses RMBG sees a missing node on CI until the testbed has triton. Importing triton needs no GPU: Krea 2's _build/prompt_check.py installs it after CPU torch, and on the soulcraft-hf runner triton 3.8.0 imported and RMBG registered its 45 nodes.

What

1. _testbed_triton runs in provision_server on Linux, right after the CPU torch install:
   • It writes testbed/.testbed-torch.txt from uv pip freeze (the torch family as installed).
   • It installs the newest triton (--upgrade) against that constraints file, so adding it never moves torch.
   • It proves the install with import triton and prints the version.
   • A miss is a warning: the build goes on and every other check still runs.
2. --status names the venv's triton on Linux, or warns that there is none.
3. --status names the packs its own server could not import, for every package: each pack ComfyUI's "Import times for custom nodes" marks (IMPORT FAILED) in this testbed's server log, or "none". A suite passes around a pack that never registered: Krea 2's CI run 39078526395 went green while RMBG failed to import, and nothing in the log said so. A server this testbed did not start is never read.
4. The requirements loop takes the bash 3.2 empty-array guard the rest of the file uses (${PACKS[@]+"${PACKS[@]}"}). Without it, a testbed with no packs died there under set -u on bash 3.2.

macOS (no triton wheels) and the pod's install are unchanged. Both PyPI and the PyTorch CPU index carry triton 3.8.0 today, cp312 to cp315.

Tests

suite/test_unit.py::test_unit_testbed_puts_triton_beside_cpu_torch_on_linux (unit tier) runs provision_server against the suite's fake uv:

• on Linux, the triton install comes after torch, after the freeze and before the requirements;
• it takes --upgrade and a constraints file holding exactly torch, torchvision and torchaudio;
• a triton that does not resolve is a warning, and the requirements and the server still follow;
• on macOS nothing asks for triton.

test_unit_testbed_status_names_the_packs_its_server_could_not_import (unit tier) runs status against canned server logs: one failed pack and one clean one (only the failed one is named), an all-clean log ("none"), and a server this testbed did not start (nothing read).

The fake uv gains pip freeze and a $UV_NO_TRITON failure; the existing testbed tests are unaffected.

Nothing ran on the Mac except bash -n, py_compile and package.py --base / --check (house rule: suites run in CI only).

Exercised on

No host yet. The base's CI runs the unit test. After the tag, a package-ci run of image-creator-krea-2 provisions the testbed with this change and should show triton in the venv and RMBG absent from the --status import report.

🤖 Generated with Claude Code