[GH-ISSUE #38] [feature request] Pass extra args to install.py on update #23

New issue

Closed

opened 2026-10-27 21:11:58 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-27 21:11:58 +00:00

Owner

Originally created by @melMass on GitHub (Jul 30, 2023).
Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/38

Hey data,

So now the recommended way to install mtb_nodes is through ComfyManager!
I think it's a better way overall and I wrote install.py in a way that can be used outside the manager too.
Because I have to ship wheels for comfy-embedded and colab I went this way:

I don't use requirements.txt so that the manager ignores it (I renamed it to reqs.txt).
from the install.py if the environment is comfy-embed or colab I first download and install the wheels from my releases (https://github.com/melMass/comfy_mtb/releases/tag/v0.1.3)
and then from install.py still I run pip install -r reqs.txt (which will detect the previously installed wheels as installed and just install the remaining ones)

Now the thing is about the manager's update, I can think of another way, but I was wondering if it would be possible to pass an extra argument to install.py when updating. It could be either a flag (--upgrade, --update), a subcommand (install.py update) or maybe even more interesting the sha of the commit from which we are updating (install.py e6919a582a1f9b9b4f0f526d88bb8955d0d9747d)

These are all just propositions and I'm not even sure they are good ideas, but I'm trying to find the best approach to handle the various systems for comfy_mtb requirements :)

Originally created by @melMass on GitHub (Jul 30, 2023). Original GitHub issue: https://github.com/Comfy-Org/ComfyUI-Manager/issues/38 Hey data, So now the recommended way to install mtb_nodes is through ComfyManager! I think it's a better way overall and I wrote install.py in a way that can be used outside the manager too. Because I have to ship wheels for comfy-embedded and colab I went this way: - I don't use `requirements.txt` so that the manager ignores it (I renamed it to `reqs.txt`). - from the `install.py` if the environment is `comfy-embed` or `colab` I first download and install the wheels from my releases (https://github.com/melMass/comfy_mtb/releases/tag/v0.1.3) - and then from `install.py` still I run `pip install -r reqs.txt` (which will detect the previously installed wheels as installed and just install the remaining ones) Now the thing is about the manager's update, I can think of another way, but I was wondering if it would be possible to pass an extra argument to `install.py` when updating. It could be either a flag (`--upgrade`, `--update`), a subcommand (`install.py update`) or maybe even more interesting the sha of the commit from which we are updating (`install.py e6919a582a1f9b9b4f0f526d88bb8955d0d9747d`) These are all just propositions and I'm not even sure they are good ideas, but I'm trying to find the best approach to handle the various systems for comfy_mtb requirements :)

bsakaguchi closed this issue

2026-10-27 21:11:58 +00:00

bsakaguchi commented

2026-10-27 21:11:58 +00:00

Author

Owner

@ltdrdata commented on GitHub (Jul 30, 2023):

https://github.com/ltdrdata/ComfyUI-Manager/tree/main/notebooks
https://github.com/ltdrdata/ComfyUI-Manager/blob/main/scripts/colab-dependencies.py

look aboves. My notebook provides automatic dependencies installation for installed nodes in colab startup.
I thinks this is better way for colab.

And Is there a specific reason to distinguish between upgrade situations and initial installation situations?

@ltdrdata commented on GitHub (Jul 30, 2023): https://github.com/ltdrdata/ComfyUI-Manager/tree/main/notebooks https://github.com/ltdrdata/ComfyUI-Manager/blob/main/scripts/colab-dependencies.py look aboves. My notebook provides automatic dependencies installation for installed nodes in colab startup. I thinks this is better way for colab. And Is there a specific reason to distinguish between upgrade situations and initial installation situations?

bsakaguchi commented

2026-10-27 21:11:59 +00:00

Author

Owner

@melMass commented on GitHub (Jul 30, 2023):

look aboves. My notebook provides automatic dependencies installation for installed nodes in colab startup.

Oh awesome, I will point that out in the instructions for Colab!

And Is there a specific reason to distinguish between upgrade situations and initial installation situations?

Mainly to be able to omit check based on updates (like pip checking requirements)

I'm currently changing a bit the install script to just use the individual wheels url that I pass directly to pip

@melMass commented on GitHub (Jul 30, 2023): > look aboves. My notebook provides automatic dependencies installation for installed nodes in colab startup. Oh awesome, I will point that out in the instructions for Colab! > And Is there a specific reason to distinguish between upgrade situations and initial installation situations? Mainly to be able to omit check based on updates (like pip checking requirements) I'm currently changing a bit the install script to just use the individual wheels url that I pass directly to pip

bsakaguchi commented

2026-10-27 21:11:59 +00:00

Author

Owner

@ltdrdata commented on GitHub (Jul 30, 2023):

look aboves. My notebook provides automatic dependencies installation for installed nodes in colab startup.

Oh awesome, I will point that out in the instructions for Colab!

And Is there a specific reason to distinguish between upgrade situations and initial installation situations?

Mainly to be able to omit check based on updates (like pip checking requirements)

I'm currently changing a bit the install script to just use the individual wheels url that I pass directly to pip

In the case of updates, since they are typically one-time events, it might be best not to skip such actions. Especially when requirements vary across different versions, fragmenting the update logic for each version can be cumbersome. Safely checking all the dependencies required for the current version is considered desirable, ensuring a more consistent and reliable software experience.

@ltdrdata commented on GitHub (Jul 30, 2023): > > look aboves. My notebook provides automatic dependencies installation for installed nodes in colab startup. > > Oh awesome, I will point that out in the instructions for Colab! > > > And Is there a specific reason to distinguish between upgrade situations and initial installation situations? > > Mainly to be able to omit check based on updates (like pip checking requirements) > > I'm currently changing a bit the install script to just use the individual wheels url that I pass directly to pip In the case of updates, since they are typically one-time events, it might be best not to skip such actions. Especially when requirements vary across different versions, fragmenting the update logic for each version can be cumbersome. Safely checking all the dependencies required for the current version is considered desirable, ensuring a more consistent and reliable software experience.

bsakaguchi commented

2026-10-27 21:12:00 +00:00

Author

Owner

@melMass commented on GitHub (Jul 30, 2023):

Ahhh yes true! I was still thinking about autoupdates so I thought this was ran on start my bad!
Then I think my new system will better fit and you are right it's not too long for a one-time event

@melMass commented on GitHub (Jul 30, 2023): Ahhh yes true! I was still thinking about autoupdates so I thought this was ran on start my bad! Then I think my new system will better fit and you are right it's not too long for a one-time event