user-configurable package version settings

[krahnikblis]

context and cause: alllllllll sorts of skill levels and programming familiarity seem to be evident in the 500+ extensions available through manager. setting aside making sense of all their naming conventions and programming style choices, one major gripe that has recently completely blocked me from being able to use Comfy at all is the package variants and versions included in everyone's requirements.txt files. my guess is, folks are just doing a pip freeze or some other mechanism that puts whatever version the author has installed into the requirements files.

problem: each time we install a new extension, a package previously installed (and functioning!) can get overwritten with a newer or older version, or a variant could be installed in parallel (the biggest pain here is OpenCV/cv2). this often works fine when it's just version - most packages don't have a lot of standard features that changed recently, and usually keep deprecated methods around for years, and most of our extension developers are not using the latest and greatest stuff, meaning most versions handle most vanilla methods everyone is using. however, there are a few places where versioning and variation are important, e.g. torch/CUDA and OpenCV. and these ones are more tied to the system configuration/environment than other packages - i.e. the choice between CUDA 11 and 12 could depend upon the user's GPU setup, and thus dictate other choices such as torch version. in my case i'm using a Docker container cuz ain't no damn way i'm letting everyone's custom scripts run freely on my system nor am i reading everyone's code... in the scenario of using a container, i need to use the "headless" version of OpenCV, which doesn't work when another version is installed at the same time.

idea for discussion: script the Manager to ignore by default all version assertions in someone's requirements file - e.g. numpy<1.24>=1.18 simply becomes numpy (rant: honestly, what is someone using that broke after 1.24??? and why not just update your code if numpy 1.26 really did get ahead of you?). the other part of this idea is user-customizable consolidation of package variants - e.g. opencv-contrib-python and opencv-python and others get re-mapped as opencv-python-headless in my customized version.

here's some scratching i did to get my head around the mess of packages across all the extensions i have (one of which updated something in a recent update, and all my Comfy stuff stopped working altogether):

from pathlib import Path

newdir = Path(r"\\wsl.localhost\docker...\ComfyUI\custom_nodes")
oldir = Path(r"\\wsl.localhost\docker...\ComfyUI_old\custom_nodes")

libreqs = {}
for appdir in [newdir,oldir]: 
	for dir in appdir.glob("*"):
		if dir.is_dir():
			reqfile = list(dir.glob("requirements.txt")) # unfortunately we can't as easily parse someone's install.py files which script these things...
			if reqfile != []:
				if reqfile[0].exists():
					with open(reqfile[0],mode="r", encoding="utf-8") as f:
						libreqs[dir.name] = [l.strip() for l in f.readlines()] # another way to rock this is to use regex patterns to match libnames

revreqs = {}
for lib, reqs in libreqs.items():
	for l in reqs:
		if revreqs.get(l) is None:
			revreqs[l] = []
		revreqs[l].append(lib)

dict(sorted(revreqs.items(),key=lambda d: d[0]))

the output of this is a reverse-indexed dict where the key is the package spec, and the value is a list of what extensions require it:

{
 'GitPython': ['ComfyUI-Manager', 'ComfyUI-Impact-Pack'],
 'Pillow': ['comfyui_controlnet_aux', 'facerestore_cf'],
 'PyWavelets': ['deforum-comfy-nodes'],
 'addict': ['comfyui_controlnet_aux',  'comfyui_segment_anything',  'facerestore_cf'],
 'albumentations': ['comfyui_controlnet_aux'],
 'cachetools': ['ComfyUI-Inspire-Pack'],
 'cmake': ['was-node-suite-comfyui'],
 'colour-science': ['ComfyUI_essentials'],
 'diffusers~=0.21.4': ['StableZero123-comfyui'],
 'einops': ['comfyui_controlnet_aux'],
 'evalidate': ['comfyui-dream-video-batches'],
 'fairscale>=0.4.4': ['was-node-suite-comfyui'],
 'filelock': ['comfyui_controlnet_aux'],
...
}

this way, i could just not re-install an extension i don't really care about, or suspect broke my environment, and use the keys above to construct the remap below...

the part that's not so special from here is, i manually started putting together a dict to hold all the stuff i found which i wanted to replace with my preferred choice. you'll see above i mentioned a regex approach to grabbing all the lib names and versions, simplifying... this won't work programmatically without some further thought, and i only have a minority of all extensions available, so i don't know what else is out there to bite me... at any rate, here's my replacement thru till when i got tired of it:

{
	'imageio-ffmpeg': 'imageio', # imageio already supports ffmpeg, no need to specify
	'imageio[ffmpeg]': 'imageio',
	'imageio_ffmpeg': 'imageio',
	'diffusers~=0.21.4': 'diffusers',
	'huggingface_hub': 'huggingface-hub', # facehuggers is just stolen other people's code anyway, why not just use the source? or copypasta that stolen code right into your own code? HACK THE PLANET!
	# 'matrix-client==0.4.0': 'matrix-nio', # different API tho, author should upgrade to new lib
	'numpy<1.24>=1.18': 'numpy', # whyyyyyyyy
 	'numpy>=1.18.5, <1.25.0': 'numpy', # whyyyyyyyy
	 # these opencv are the problematic ones:
	'opencv-contrib-python': 'opencv-contrib-python-headless',
	'opencv-python': 'opencv-contrib-python-headless',
	'opencv-python-headless': 'opencv-contrib-python-headless',
	'opencv-python-headless[ffmpeg]<=4.7.0.72': 'opencv-contrib-python-headless',
	'opencv-python>=4.7.0.72': 'opencv-contrib-python-headless',
 	'pandas<=1.5.1': 'pandas',
	'scikit-image==0.20.0': 'scikit-image',
	'scipy>=1.11.4': 'scipy',
 	'segment_anything': 'segment-anything',
	'timm==0.6.5': 'timm',
	'timm>=0.4.12': 'timm',
 	'transformers==4.26.1': 'transformers',
}

with these replacements, pip install -U will just get the latest package, and any variant of something i need a custom version for (e.g. opencv) will not get messed up (i guess until a new variant comes along i haven't seen before?). if we use regex to strip version numbers and various [option] identifiers and replace "_" with "-", then the user customization would really be around packages with variation, and allow for a user to specify "yo i gotta use CUDA 11.8 because reasons" and not get messed up by someone's requirements file.

so, that's all i have for this dump of an idea, now of course the question is, what would this break, and is that better/worse than what the existing free-for-all already breaks?

[ltdrdata]

This seems like a good idea.
It may not be able to handle special cases such as installing packages directly in install.py, but fundamentally, this seems like a good direction.

[ltdrdata]

This is implemented.
https://github.com/ltdrdata/ComfyUI-Manager#additional-feature

[HansonChan]

After I reinstalled opencv several times, glad to see this.
If the readme included a user guide, it would be better.

[geroldmeisinger]

'opencv-contrib-python': 'opencv-contrib-python-headless',
'opencv-python': 'opencv-contrib-python-headless',
'opencv-python-headless': 'opencv-contrib-python-headless',
'opencv-python-headless[ffmpeg]<=4.7.0.72': 'opencv-contrib-python-headless',
'opencv-python>=4.7.0.72': 'opencv-contrib-python-headless',

I'd argue these should remap to opencv-contrib-python as the superset. I know ComfyUI is often used in a server and browser environment and shouldn't make calls to cv2.imshow (=non-headless). the headless version mostly exist to avoid dependencies to GUI libs (X11, QT, GTK etc.) "to save disk space"... which in the context of generative AI is a weak argument. torch has several gigs, SD1 has several gigs. there is not point in saving disk space.

[ltdrdata]

This is just a optional thing.
If this is not applied, the remap function will not be activated.
You can edit the remap file to match your environment and then apply it.

[HansonChan]

For Mac M chips users, maybe adding the following config to example file is helpful

"onnxruntime-silicon": "onnxruntime-gpu"

[ltdrdata]

Is it correct to try installing 'onnxruntime-gpu' instead of 'onnxruntime-silicon'?

[HansonChan]

Is it correct to try installing 'onnxruntime-gpu' instead of 'onnxruntime-silicon'?
Sorry.
I am troubleshooting some custom nodes' errors on a Mac with an M-series chip. Initially, during the process of upgrading ComfyUI, the version of OpenCV kept getting replaced, which led me to find this issue. I misunderstood what you mentioned; on a Mac, it should be onnxruntime-silicon replacing onnxruntime-gpu. However, I haven't tested whether all functionalities that reference onnxruntime-gpu work correctly. The reply about is just an idea or suggustion.

[ltdrdata]

pip_overrides.osx.template is added.