Decide if we change to the refractored FooocusAPI

[davefojtik]

Mrhan started working on his own refractored version some time ago, implementing the FastAPI right into the Fooocus, not as a wrapper around it. The future of the current Fooocus-API repo is not known yet. The new version is quite different, and would require everyone to rewrite their code and payloads. Here, we can discuss which way to go.

[pribeh]

It looks like the future of the Fooocus library is now in flux as both maintainers have indicated they are putting it into maintenance mode. I think at this point possibly the best course of action would be to adapt the existing version of Fooocus-API and then see what happens with Fooocus itself. I know we're certainly debating what to do.

I tried updating to the latest version of Fooocus-API 0.5.0.1 but was running into some errors. Do you know what are the most important files and components to take a look at other than the requirements when updating to the 0.5.0.1 release?

[davefojtik]

Really? The last time I checked they said Flux is impossible or not ready to be implemented, although it would be great news!
I also asked Mrhan about the future of the API here. It looks like the FooocusAPI and Fooocus-API will basically be the same in the future anyway. So I started a dev branch where I already did some work on handler.py to prepare it for the new endpoints and possible generator_handler (Still WIP, not tested!)

For updates, I usually do the following:

• Download the latest commit of the API code version I want the update to support, build it, and run it locally.
• Inspect the local docs, git changes, and changelogs of both Fooocus-API and Fooocus for major changes that need to be addressed.
• Change the RunPod code accordingly and test it locally with python handler.py --rp_serve_api (RunPod python SDK installed in your environment is needed to do so. See more about local testing)
• Go through the changes once more and ensure there are no new models or things to be downloaded and baked into the image
• Update the dockerfiles if needed
• Build and push the dev version, deploy it on my endpoint and thoroughly test the whole API

Correct handler.py is needed to make it work locally. requirements.txt, start.sh and dockerfiles to make it work on the cloud endpoint. And networksetup.sh for the NetworkVolume variant.

Let's see the errors you're facing. You should be able to open a pull request with code changes and we can work on the problems together there.

[pribeh]

@davefojtik I'm sorry I meant to suggest that the maintainers have put the library into maintenance mode. We're now considering whether or not to fork the library. We're definitely going to keep using it along with your runpod code here for awhile longer.

Thanks for getting started on a dev branch and sharing the above – I really mean that. I will start testing this weekend and then report back. I'll try to fix any issues I come across first

[davefojtik]

I see. The future indeed seems to be Flux and Fooocus would need the support for it to keep going. With Mashb1t stepping out there's no one to maintain it. The solution for Mrhan and FooocusAPI would be to use a different fork of Fooocus that already has Flux implemented, like metercai/SimpleSDXL, but that also means rewriting the API once again.

This is the harsh reality of the AI world. Everything improves so fast, but that also means the software implementing it is ageing at the same speed. And as the next hype wave comes, the solutions we spent months on become useless. So far only the "main" projects like A11 and Comfy seem to hold through the time.