Handle async funcs within sync scopes

[omerXfaruq]

Description

1. Creates utility functions for running async coroutines within sync scopes. It was quite troublesome to create proper solutions for this, finally resolved.
2. Gives async support to using demo("input") programmatically. Which was introduced in a recent PR recently that I can't find right now 🐱

[abidlabs]

@farukozderim is there any way we can avoid adding another dependency to gradio? Especially as fsspec has < 500 stars.

I took a quick look at the fsspec.asyn.sync() function and it doesn't seem to be too complex, can we just implement it as a utility function ourselves? https://filesystem-spec.readthedocs.io/en/latest/_modules/fsspec/asyn.html

[omerXfaruq]

Why do you want to avoid adding another dependency?

I think this is a needed dependency, why implement a complex functionality that deals with async, threading and multiple event loops when there is a library handling it? I just played around for a bit, and I don't think it will be easy or quick to get it safe&right ourselves and adding the dependency causes no problems, we should add a dependency when we need it.

Btw I don't think fsspec having 500 stars is a dangerous situation, because it has very decent maintainers/contributors.

[abidlabs]

Why do you want to avoid adding another dependency?

For all of the standard reasons: security, increased installation time, dependency conflict, etc. I'm not totally against adding a new dependency, but since it looks like we are using a single function, purely written in Python, from this dependency (or am I mistaken about that?), I think we should at least consider implementing it ourselves

[omerXfaruq]

I think we should at least consider implementing it ourselves

Agreed, this sounds good but

I think this is a needed dependency, why implement a complex functionality that deals with async, threading and multiple event loops when there is a library handling it? I just played around for a bit, and I don't think it will be easy or quick to get it safe&right ourselves

Additionally, I think that repeating complex processes is unnecessary, and resource consuming. And If we're going to copy&paste the related functions I would prefer to use the library instead. Libraries exist for this reason 😄

Open to suggestions about this or you can also take it if you think it'd help a lot or see a clean&easy way of implementing it ourselves.

Could also take @aliabid94's opinion on this, it might help.

[aliabid94]

there was a discussion in hf tech slack channel today actually about importing vs reimplementing libraries, seems like the general idea was just reimplement to keep a library lightweight if only using a small part of it.

[omerXfaruq]

I don't think we're currently a lightweight project(considering our dependencies and tarball size), and reimplementing a complex library handling multiple event loops + multithreading + async coroutines does not look like a good approach to me 😸

[omerXfaruq]

Let's merge this PR for now to unblock this, and remove the fsspec dependency if we implement the functionality ourselves in the future?

[abidlabs]

Just taking a look into the PR now @farukozderim!

[abidlabs]

Why are these changes inside the gradio.egg-info here? Can we remove them to clean up the PR?

[omerXfaruq]

Are you talking about all of them or some of them?
These are automatically generated when I used bash install_gradio.sh, it seems my machine generates it a little different, could you also try running it on your machine, maybe that will fix them?

[abidlabs]

Interesting ok

[abidlabs]

Ok yeah it seems like we would also have to implement fsspec.asyn.get_loop() which requires rewriting a lot of code ourselves, so agree with @farukozderim let's just incorporate this dependency.

Tested and everything works well. LGTM!