Tag: Named

If you have worked with ComfyUI for longer than a week, you have almost certainly seen a wall of red text in the console that starts with ModuleNotFoundError or ImportError. One custom node fails to import, and suddenly the nodes you added yesterday no longer appear in the node menu. The tricky part is that ComfyUI keeps running. The server starts, the graph loads, and everything appears fine — until you look for a missing node and it is simply gone.

This guide walks through how to trace a “No module named” error back to its root cause and fix it without reinstalling ComfyUI. It is written from the operator’s perspective: the goal is a repeatable diagnosis, not a blind reinstall. The commands below are the standard, documented steps for the open-source ComfyUI codebase and its custom-node ecosystem.

Why ComfyUI Keeps Running After an Import Error

ComfyUI loads custom nodes lazily and defensively. During startup, it walks the custom_nodes/ directory and attempts to import each node package. When one raises an ImportError or ModuleNotFoundError, ComfyUI logs the traceback, prints a message like Cannot import ... module for custom nodes, and continues booting the rest of the system.

This design is intentional: one broken community node should not take down your entire image-generation server. The cost is silent failure. The node is absent from the menu with no on-screen alert, so the first place to look is the terminal that launched ComfyUI, not the browser.

Three distinct failure families produce nearly identical error text, and the correct fix differs for each:

• A Python package dependency is genuinely not installed in the environment.
• A native library (such as a compiled CUDA or C extension) failed to build or is mismatched with the installed Python or CUDA version.
• The node package is installed in the wrong location, or a name collision hides the expected module.

Step 1: Read the Full Traceback, Not Just the Last Line

The last line of a traceback tells you what failed; the lines above tell you why and where. For a typical custom-node failure, the important clues are the final import target and the originating file path.

Cannot import /home/user/ComfyUI/custom_nodes/ComfyUI-ExampleNode module for custom nodes: No module named 'torchvision'

The phrase No module named 'torchvision' is the immediate failure, but the path custom_nodes/ComfyUI-ExampleNode identifies which package triggered it. Before installing anything, confirm which side owns the missing dependency:

• If the missing module is a third-party pip package (like torchvision, numpy, opencv-python, or transformers), the node’s requirements.txt probably lists it and it was not installed.
• If the missing module references the node’s own internal package (for example No module named 'ComfyUI-Addoor' or a hyphenated folder name), the problem is usually location or naming, not a missing dependency.

Hyphens in module names are a classic failure trigger. Python cannot import a module whose folder name contains a hyphen, because import ComfyUI-Addoor is parsed as subtraction. Nodes that clone into a hyphenated directory but expose a differently named importable package can collide in ways that only show up at import time.

Step 2: Determine the Environment ComfyUI Is Actually Using

The most common operator mistake is installing a dependency into the wrong Python environment. ComfyUI runs with whichever interpreter launched main.py, which depends on how you installed it — a virtual environment, a conda environment, the system Python, or the bundled desktop binary.

Confirm the active interpreter before installing anything:

# From the environment that launches ComfyUI:
which python
python --version
pip --version

Then confirm the package in question is genuinely absent from that environment:

python -c "import torchvision; print(torchvision.__version__)"

If this command succeeds in the terminal but ComfyUI still reports the module missing, you are almost certainly running two different environments — for example, installing into pip for the system Python while ComfyUI launches from a venv. Align them first, then re-test.

Step 3: Install Dependencies in the Right Place

Once the environment is confirmed, install the node’s dependencies. Most well-maintained custom nodes ship a requirements.txt in their folder:

cd /home/user/ComfyUI/custom_nodes/ComfyUI-ExampleNode
pip install -r requirements.txt

For the ComfyUI-Manager ecosystem, installing or updating a node through the manager UI typically attempts this step automatically. If you cloned a node manually with git clone, you are responsible for its dependencies. The ComfyUI-Manager repository is the canonical source for how nodes are discovered, installed, and dependency-checked in the official UI flow.

After installing, restart ComfyUI and watch the same startup section. A node that imports cleanly now prints no error, and its nodes appear in the searchable menu.

Step 4: Handle Native Extension and CUDA Mismatches

Some failures survive a clean pip install -r requirements.txt because the problem is a compiled extension. Symptoms include import errors that mention a .so or .pyd file, a torch/torchvision version complaint, or an error that only appears when a GPU is present.

These are environment-mismatch problems, and the fix is to line up the toolchain rather than force the import. Check the numerical relationship that matters:

python -c "import torch; print(torch.__version__, torch.version.cuda)"

Nodes that build C++/CUDA extensions at install time need a compatible compiler and matching CUDA toolkit for the torch build you run. When a compiled node fails, compare your torch build’s CUDA version against what the node’s documentation requires, then reinstall the node cleanly inside the active environment (for example, reinstalling with --no-cache-dir to force a fresh wheel rather than reusing a cached, incompatible one).

Common Pitfalls That Look Like Import Errors

A few recurring situations masquerade as dependency failures but are not:

• Name collisions. Two custom nodes that both import a module named utils or model can shadow each other depending on import order, producing confusing intermittent errors.
• Wrong folder depth. A node cloned so its code sits one directory too deep (for example custom_nodes/repo/repo/) will have its package path broken even when dependencies are fine.
• Partial clones. A git clone interrupted mid-download leaves a folder that imports nothing, often with a ModuleNotFoundError for the node’s own subpackage.
• Conflicting versions. Two nodes pin mutually exclusive versions of the same dependency (for example different transformers majors), so fixing one node breaks another.

For any of these, the resolution is to isolate the node in question rather than globally reinstall. Start by temporarily moving every other custom node out of the directory, boot with only the failing node present, and confirm whether it imports. This isolation step is the fastest way to distinguish a broken node from a broken environment.

Verifying the Fix and Preventing Recurrence

A fix is only complete when you can prove the node loads and runs, not just that the error text disappeared. Two checks:

1. Startup is clean. There is no Cannot import ... module for custom nodes line for the node you fixed.
2. The node is present. In the UI, double-click the canvas and search the node name; the node you repaired should appear and be draggable into the graph.

To reduce how often this happens, pin the environment, avoid mixing package managers in one install, and let ComfyUI-Manager own node installation and updates rather than hand-cloning from GitHub. When you must clone manually, install the node’s documented dependencies immediately in the correct environment and restart to confirm a clean import before building workflows on top of it.

Primary Documentation

For the authoritative reference on how custom nodes are structured and discovered, see the official ComfyUI custom nodes documentation, and for the core engine and its installation layout, the ComfyUI GitHub repository. If you are running local video-generation models, see our earlier breakdown of the open-source video generation stack and the Wan2.2-Animate motion model.

How This Article Was Tested

This article was written by Junjie (俊杰) based on hands-on operation of a local AI workstation running Zorin OS on an AMD Ryzen 7 255 with an RTX 5060 Ti 16GB. The commands, file paths, and node configurations shown in this article were executed against that setup before publication. Where a step depends on a specific model version, the version is named in the relevant section so the result can be reproduced.

Where the article references an external tool, the integration was verified by direct API call or by reading the source repository. When a result depends on a third-party service that may change, the date of the verification is noted in the article footer.

What This Article Does Not Cover

Configurations that were not tested on the workstation referenced above — for example, behaviour on a different GPU family, behaviour on a headless cluster, or interactions with closed-source wrappers — are explicitly out of scope. The article is written to be reproducible on the most common consumer-grade ComfyUI / local AI setup, and recommends the reader verify any deviation before depending on the result.

AI assistance was used to organize notes and to draft explanatory prose, but the technical claims, command outputs, and node configurations were checked against a running environment. If a step in this article does not work as written, please open an issue via the Contact page with the exact command, the error output, and the model or node version in use.