Add pyproject.toml for Custom Node Registry

[haohaocreates]

We are working with dr.lt.data and comfyanon to build a global registry for custom nodes (similar to PyPI). Eventually, the registry will be used as a backend for the UI-manager. All nodes go through a verification process before being published to users.

The main benefits are that authors can

• publish nodes by version and users can safely update nodes knowing ahead of time if their workflows will break or not
• automate testing against new commits in the comfy repo and existing workflows through our CI/CD dashboard

Action Required:

• Go to the registry. Login and create a publisher id. Add the publisher id into the pyproject.toml file.
• Write a short description.
• Merge the separate Github Actions PR and run the workflow.

If you want to publish the node manually, install the cli and run comfy node publish

Check out our docs if you want to know more about the registry. Otherwise, feel free to message me on discord at haohao_81202 or join our server if you have any questions!

[haohaocreates]

hey @Nlar, wanted to send a small nudge and ask if you had any questions!

[haohaocreates]

@Nlar, wondering if there's any way we can support you on this PR!

[Nlar]

If the repository had a way to clearly show the required cuda version I would go ahead. Ideally, if the text could be similar to the checks for compatibility between nodes for stating requirements. My concern is that users will download the node, have it crash and then uninstall the node. Yes, RTM should be absolute, but I would prefer that the requirements be highlighted rather than give a poor impression to those under time constraints.

[haohaocreates]

Hey @Nlar ! These are great points to flag, I just touched base with Data and these are some of his thoughts:

- I believe it is necessary to provide users with clear feedback regarding some key dependencies.

- Currently, ComfyUI-Manager has minimal safeguards to prevent the reinstallation of ComfyUI core dependencies from custom nodes. However, I believe it is also necessary to provide information about important packages such as diffusers.

- Additionally, I believe it is necessary to manage frequently reported package conflicts proactively.

- I would like the CNR API to provide information about such potential conflicts.

- In cases of such conflicts, it would be better to proceed by getting confirmation from the user before installation.