Add FrontendManager to manage non-default front-end impl

[huchenlei]

This PR adds an extra cmd arg --front-end-version which can be used to manage what front-end to use.

Arg help:

  --front-end-version FRONT_END_VERSION
                        Specifies the version of the frontend to be used. This command needs internet connectivity to query and download available frontend implementations from GitHub releases. The    
                        version string should be in the format of: [repoOwner]/[repoName]@[version] where version is one of: "latest" or a valid version number (e.g. "1.0.0")
  --front-end-root FRONT_END_ROOT
                        The local filesystem path to the directory where the frontend is located. Overrides --front-end-version.

--front-end-version=Comfy-Org/ComfyUI_frontend@latest

It is recommended for all developers to use this arg to keep up with latest version of front-end.

--front-end-version=Comfy-Org/[email protected]

Always checkout a specific release version. This is useful for people who want to fall back to previous versions if the latest release breaks something.

--front-end-root={front-end checkout path}

If you have difficulty accessing github release, you can manually download the frontend impl you want to use and reference it using this argument. --front-end-root overrides the value set in --front-end-version.

You can observe following log on startup to get knowledge about which directory is used as active web root.

Downloading frontend(Comfy-Org_ComfyUI_frontend) version(1.1.0) to (D:\ComfyUI_windows_portable\ComfyUI\web_custom_versions\Comfy-Org_ComfyUI_frontend\1.1.0)
[Prompt Server] web root: D:\ComfyUI_windows_portable\ComfyUI\web_custom_versions\Comfy-Org_ComfyUI_frontend\1.1.0```


No more new features should be added to the legacy UI, as we start the migration to the TS repo. There will be another PR adding a Github Action to warn any change on `web/` directory. In the future, `web/` directory should only host the compiled default frontend impl.

[huchenlei]

Optional

We should also be able to host alternative front-end impl like

• https://github.com/sdfxai/sdfx
• https://github.com/MaxTretikov/SabreUI
  by adding extra FrontendProvider entries to the list.

[huchenlei]

From @comfyanonymous offline:
The frontend_management should also work if access to github is blocked, e.g. GFW.

[huchenlei]

From @comfyanonymous offline: The frontend_management should also work if access to github is blocked, e.g. GFW.

Done by adding --web-root option to allow user just ref a file system path as web-root.

[MaxTretikov]

Adding Sabre would be appreciated on our side 🙏, also just to confirm: --web-root accepts URLs that point to a dist?

We should also add a way to access this setting from the UI rather than just cli args.

[huchenlei]

Adding Sabre would be appreciated on our side 🙏, also just to confirm: --web-root accepts URLs that point to a dist?

We should also add a way to access this setting from the UI rather than just cli args.

Distribute frontend impl with git repo

--web-root is pointing the web_root to a local file system directory. It does nothing else. If I am reading it correctly, you are suggesting that we do the frontend impl the same as custom node where we just checkout the git repo, and update them in some way. I do not like this approach, as front-end impl is not like custom node as you are hosting compiled code in that proposed front-end repo. There is very little benefit on version control compiled code with git. If you want to ship fast and make every commit in your frontend repo to be accessed immediately by your users, you can setup a github action to automatically create release when new commit is created in your repo.

Switch Front-End Impl on UI

For the front-end picker on UI, we want to design a mechanism that allow front-end impl to persist the choice of front-end on the web UI without making user go and edit --front-end-version cmd arg. This issue can be further discussed as there are definitely more details on how do we ensure/incentivize that all thirdparty frontend implements this. If A implements this and make it easy to switch to B, but B does not implements it and it becomes hard to switch back to A, users get stuck on B.

I think this is a separate topic and should not be included in this PR.

[MaxTretikov]

Distribute frontend impl with git repo

--web-root is pointing the web_root to a local file system directory. It does nothing else. If I am reading it correctly, you are suggesting that we do the frontend impl the same as custom node where we just checkout the git repo, and update them in some way. I do not like this approach, as front-end impl is not like custom node as you are hosting compiled code in that proposed front-end repo. There is very little benefit on version control compiled code with git. If you want to ship fast and make every commit in your frontend repo to be accessed immediately by your users, you can setup a github action to automatically create release when new commit is created in your repo.

Sorry I think I wasn't clear -- in the chat I mentioned having ComfyUI manage version control but that's not what I mean here. I mean that if a URL is passed to the arg it tries to download it assuming it's a zipped dist/ directory. That way, as an alternate frontend developer, it's just one line to install and run the frontend rather than asking users to clone/download it and pass the directory to the arg. I feel less technically inclined users might have hiccups with absolute/relative file paths. Also, this is how many other CLI args in different apps that allow users to specify a filepath work, and the name web-root I think implies that functionality.

Switch Front-End Impl on UI

For the front-end picker on UI, we want to design a mechanism that allow front-end impl to persist the choice of front-end on the web UI without making user go and edit --front-end-version cmd arg. This issue can be further discussed as there are definitely more details on how do we ensure/incentivize that all thirdparty frontend implements this. If A implements this and make it easy to switch to B, but B does not implements it and it becomes hard to switch back to A, users get stuck on B.

It should definitely be possible to inject a little JS header that allows the user to immediately switch back to legacy with a keyboard shortcut, and I can look into that. It would be nice if we could somehow detect load failures as well on the server to automatically boot back into legacy.

[huchenlei]

Sorry I think I wasn't clear -- in the chat I mentioned having ComfyUI manage version control but that's not what I mean here. I mean that if a URL is passed to the arg it tries to download it assuming it's a zipped dist/ directory. That way, as an alternate frontend developer, it's just one line to install and run the frontend rather than asking users to clone/download it and pass the directory to the arg. I feel less technically inclined users might have hiccups with absolute/relative file paths. Also, this is how many other CLI args in different apps that allow users to specify a filepath work, and the name web-root I think implies that functionality.

--web-root argument is intentionally not accessing the internet. I would strongly suggest custom front-end developers to follow the github release practice instead of passing a fixed URL for better version management.

It should definitely be possible to inject a little JS header that allows the user to immediately switch back to legacy with a keyboard shortcut, and I can look into that. It would be nice if we could somehow detect load failures as well on the server to automatically boot back into legacy.

You can file a new issue discussing this option. We should stop the discussion on this topic here.

[huchenlei]

@comfyanonymous Gentle ping on the review

[qudix]

very minor thing, but for consistency couldn't --web-root be renamed to --front-end or --front-end-path (though I suppose you'd want to keep backwards compat)?

[huchenlei]

very minor thing, but for consistency couldn't --web-root be renamed to --front-end or --front-end-path (though I suppose you'd want to keep backwards compat)?

Renamed --web-root to --front-end-root for consistency.

[comfyanonymous]

Why does there need to be a hardcoded list of providers?

[huchenlei]

What concerns do you have on hardcoded provider list? I don't think it's necessary to make the provider list loaded dynamically. At least for now.

[huchenlei]

Offline discussion: Get rid of provider list and let peope directly use URL to specify frontend provider.

[comfyanonymous]

  File "/mnt/fast_ssd/stable_diff/comfy_ui/app/frontend_management.py", line 150, in add_argument
    def is_valid_directory(path: str | None) -> str | None:
TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'

I get this error on python 3.9

[comfyanonymous]

comfy/cli_args.py should not import this file.

[comfyanonymous]

Things inside the comfy folder should not depend on things outside of it.

[huchenlei]

Inlined.

[huchenlei]

  File "/mnt/fast_ssd/stable_diff/comfy_ui/app/frontend_management.py", line 150, in add_argument
    def is_valid_directory(path: str | None) -> str | None:
TypeError: unsupported operand type(s) for |: 'type' and 'NoneType'

I get this error on python 3.9

3.10 type syntax replaced with 3.9 compatible syntax.

[MasterIO02]

This seems to breaks Python 3.8:

Traceback (most recent call last):
[ComfyUI-0/STDERR]   File "main.py", line 81, in <module>
[ComfyUI-0/STDERR]     import server
[ComfyUI-0/STDERR]   File "/home/StableDiffusion/StableSwarmUI/dlbackend/ComfyUI/server.py", line 28, in <module>
[ComfyUI-0/STDERR]     from app.frontend_management import FrontendManager
[ComfyUI-0/STDERR]   File "/home/StableDiffusion/StableSwarmUI/dlbackend/ComfyUI/app/frontend_management.py", line 24, in <module>
[ComfyUI-0/STDERR]     class Release(TypedDict):
[ComfyUI-0/STDERR]   File "/home/StableDiffusion/StableSwarmUI/dlbackend/ComfyUI/app/frontend_management.py", line 32, in Release
[ComfyUI-0/STDERR]     assets: NotRequired[list[Asset]]
[ComfyUI-0/STDERR] TypeError: 'type' object is not subscriptable

What's the minimal recommended Python version to run ComfyUI? 3.9?

[teward]

What's the minimal recommended Python version to run ComfyUI? 3.9?

@MasterIO02 I personally would not use anything older than 3.10 for StableDiffusion stuff. The subscript typing stuff is I believe in 3.9, but may have been 3.10.

[MasterIO02]

What's the minimal recommended Python version to run ComfyUI? 3.9?

@MasterIO02 I personally would not use anything older than 3.10 for StableDiffusion stuff. The subscript typing stuff is I believe in 3.9, but may have been 3.10.

@teward I see. I'm stuck with Python 3.8 because SwarmUI doesn't seem to allow us to change the used Python version and just uses the default system-wide one, which cannot really be upgraded on Ubuntu 20 without breaking the whole system. Will eventually upgrade to use a newer Python version 🫡

[teward]

What's the minimal recommended Python version to run ComfyUI? 3.9?

@MasterIO02 I personally would not use anything older than 3.10 for StableDiffusion stuff. The subscript typing stuff is I believe in 3.9, but may have been 3.10.

@teward I see. I'm stuck with Python 3.8 because SwarmUI doesn't seem to allow us to change the used Python version and just uses the default system-wide one, which cannot really be upgraded on Ubuntu 20 without breaking the whole system. Will eventually upgrade to use a newer Python version 🫡

Not sure if you can install a separate Python on SwarmUI but you could potentially if you have system access to install devel building packages can use pyenv or such to install a different python in userspace to execute things with.

[teward]

What's the minimal recommended Python version to run ComfyUI? 3.9?

@MasterIO02 I personally would not use anything older than 3.10 for StableDiffusion stuff. The subscript typing stuff is I believe in 3.9, but may have been 3.10.

@teward I see. I'm stuck with Python 3.8 because SwarmUI doesn't seem to allow us to change the used Python version and just uses the default system-wide one, which cannot really be upgraded on Ubuntu 20 without breaking the whole system. Will eventually upgrade to use a newer Python version 🫡

Keep an eye on #4035 which has a compatibility fix (not yet merged)