[GH-ISSUE #937] Is there a way for all nodes to share the most commonly used dependencies while independently using less popular dependencies? #411

New issue

Open

opened 2026-10-27 21:17:14 +00:00 by bsakaguchi · 2 comments

bsakaguchi commented

2026-10-27 21:17:14 +00:00

Owner

Originally created by @planb788 on GitHub (Aug 6, 2024).
Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/937

One common issue we often encounter is that when installing a new plugin, there may be conflicts between the dependency versions it specifies and the existing dependencies on the local system.
Is there a way to create a virtual environment where all plugins share the same common dependencies (such as the torch library), and then for each plugin's dependencies that are not in the common dependencies, create an additional separate virtual environment, so that each plugin can enjoy its own independent dependencies plus the shared common dependencies?
This approach maintains the independence of the environment while also reducing redundant dependencies to some extent.

Originally created by @planb788 on GitHub (Aug 6, 2024). Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/937 One common issue we often encounter is that when installing a new plugin, there may be conflicts between the dependency versions it specifies and the existing dependencies on the local system. Is there a way to create a virtual environment where all plugins share the same common dependencies (such as the torch library), and then for each plugin's dependencies that are not in the common dependencies, create an additional separate virtual environment, so that each plugin can enjoy its own independent dependencies plus the shared common dependencies? This approach maintains the independence of the environment while also reducing redundant dependencies to some extent.

bsakaguchi commented

2026-10-27 21:17:15 +00:00

Author

Owner

@ltdrdata commented on GitHub (Aug 6, 2024):

While it's possible to separate environments using venv, you can only run one environment at a time, so you can't use two custom nodes that cause conflicts simultaneously.

@ltdrdata commented on GitHub (Aug 6, 2024): While it's possible to separate environments using venv, you can only run one environment at a time, so you can't use two custom nodes that cause conflicts simultaneously.

bsakaguchi commented

2026-10-27 21:17:15 +00:00

Author

Owner

@planb788 commented on GitHub (Aug 7, 2024):

While it's possible to separate environments using venv, you can only run one environment at a time, so you can't use two custom nodes that cause conflicts simultaneously.

Indeed, that's the case. So currently, if there are conflicting nodes, can we only choose one of the two? It seems like this might be an unsolvable problem.

@planb788 commented on GitHub (Aug 7, 2024): > While it's possible to separate environments using venv, you can only run one environment at a time, so you can't use two custom nodes that cause conflicts simultaneously. Indeed, that's the case. So currently, if there are conflicting nodes, can we only choose one of the two? It seems like this might be an unsolvable problem.

bsakaguchi referenced this issue

2026-10-27 21:30:06 +00:00

[PR #411] [MERGED] Update model-list.json #1316