Library Finder 🔍

Library Finder 🔍 answers one very specific, very annoying question: which of my dozens of custom nodes is importing numpy (or torch, or omegaconf, or whatever's blowing up)? If you've ever chased an ImportError through your ComfyUI install, or wondered whether you can finally delete that node pack that pulls in a library you hate, this is the tool for the job.

It's a tiny utility from RiverSide71, and it does exactly what the name says. You hand it a comma-separated list of library names, it greps every folder in ComfyUI/custom_nodes/ - both the .py imports and the requirements.txt files - and prints a tidy report of who uses what. No API calls, no model downloads, no key. The entire node is one Python file with zero dependencies beyond the standard library.

Why you'd actually reach for it

ComfyUI's custom node ecosystem is dependency hell by design. Each node installs into the same Python environment, so conflicts are structural, not accidental - Node A wants transformers==4.30, Node B wants transformers>=4.40, and pip resolves it however pip resolves it. This node is your forensics tool for that mess: when a library breaks, you can see every node that touches it in one go instead of guessing.

It's also handy for two quieter jobs. First, auditing: before you trust a pack, you can check whether it imports anything you'd rather not have around. Second, tidying: find out which node is the only consumer of a heavy library you want gone, and remove it with confidence.

How it works

The mechanism is plain text scanning, and the source is small enough to read in a minute. It walks ComfyUI/custom_nodes/, skips its own folder, and checks each sibling:

• requirements.txt files - it normalizes dashes and underscores, strips comments, and matches the library name with an optional version specifier. If you type torch>=2.0 and a node pins a different version, it won't claim a match.
• Every .py file - regex for import x and from x ... at line starts, walking subdirectories (skipping __pycache__ and dotfolders).

On top of the node-level matches, it reports the installed version of each library via importlib.metadata, and flags whether a matching node pinned a version in its requirements. That version column is the quietly useful part - it's the difference between "someone uses torch" and "three packs pin conflicting torch versions."

Inputs and outputs

There's exactly one input and one output, so nothing to get lost in:

• libraries (STRING) - comma-separated library names. Defaults to torch, numpy; the placeholder hints torch, opencv-python, requests. You can include a version specifier like transformers>=4.40, though the bare name is usually what you want.
• result (STRING) - the full formatted report: the scanned path, each library with its installed version, each matching node folder, the source files that matched, and a total-match count at the bottom.

The node is flagged as an output node, so the report shows up in the UI right away. It's still a regular STRING output, so you can wire it into any text display node if you'd rather keep the report in the graph. Don't chain it into generation nodes - it's a text/utility node, full stop.

Installation

The easy way: open ComfyUI Manager, search for comfyui-library-finder (publisher river-side), and hit install. It's registered in the Comfy Registry, so Manager finds it.

Manual way, from the README:

cd ComfyUI/custom_nodes
git clone https://github.com/RiverSide71/comfyui-library-finder.git

Then restart ComfyUI. That's it - no requirements.txt, no models, no CUDA version to babysit. This is as close to a zero-friction install as custom nodes get.

Where people get burned

Honestly, the traps are mild, but they exist:

• It only scans custom_nodes/. Core ComfyUI internals and anything installed outside that folder are invisible to it. A library that errors from core code won't show up, which is correct behavior, just easy to misread as "nothing uses it."
• Matching is text-based, not semantic. Dynamic imports (importlib.import_module("torch")), aliasing, and package name games slip past the regex. If you search cv2 and get nothing, double-check whether a node imports cv2 plainly or hides it behind something else.
• It skips its own folder. Cosmetic, but a search for re or os won't list the node that's doing the searching.

The README's own "known limitations" section is empty, which for a node this small is almost believable. If it misses something, the author asks you to file an issue - the source is short enough that a patch is a twenty-minute job for anyone handy with regex.