Building interactive demos for examples

### Describe the issue linked to the documentation

This is not an issue but rather a good-to-have feature for documentation and this issue is more of a discussion.

It would be nice to have links to or embedding interactive demos made with Gradio inside documentation. 
I've built two apps that you might see how it looks like:
- Anomaly detection: https://huggingface.co/spaces/scikit-learn/anomaly-detection
- Classification: https://huggingface.co/spaces/scikit-learn/classification

We can have below demo (but more official version 😅) embedded in your documentation.
<img width="1155" alt="Ekran Resmi 2022-11-10 15 11 41" src="https://user-images.githubusercontent.com/53175384/201114005-5fd13d40-990a-412d-abe6-fdd01d0f87d9.png">

The current workflow for users is to download python code or run binder. This reduces amount of work in this workflow too!
If you think embedded demos is a bit overkill what we could do is to create these demos and host them on [Spaces](https://huggingface.co/spaces) and put link to Space instead (like it is with Keras examples or kornia examples, you can see them [here](https://huggingface.co/keras-io) and [here](https://huggingface.co/kornia), they're linked from their tutorials on both [Keras.io/examples](https://keras.io/examples/) and Kornia docs) We will also host the Spaces in better hardware (8 vCPU 32 GiB RAM) to make sure it's always running and all good. ✨ 

You can see how it's implemented in Kornia for rst docs [here](https://raw.githubusercontent.com/kornia/kornia/627ebcaaab1547c362908fc9ad9a68c6316c5993/docs/source/filters.rst). It looks like [this](https://kornia.readthedocs.io/en/latest/filters.html#interactive-demo) inside Kornia docs.

<img width="1353" alt="Ekran Resmi 2022-11-10 15 15 08" src="https://user-images.githubusercontent.com/53175384/201114865-d44b6af5-0b85-44d1-b490-0450d8ea05aa.png">

As for Keras, we just put a redirection link inside docs since their document generation is more layered.  
<img width="1309" alt="Ekran Resmi 2022-11-10 15 09 57" src="https://user-images.githubusercontent.com/53175384/201113694-a4c5b804-dce4-4e72-b23e-bbe449bbc150.png">

We definitely want to reduce the core maintainers' workflow so what would be cool is that we (team at [Gradio](https://gradio.app/) & community)  will be developing the demos and maintaining them through GitHub actions such that they will not break every time there's a breaking change in sklearn (this happens rarely, though 🙂)

Hoping to see how we could collaborate!

COMMENT:
I think having interactive examples really helps people get a feeling for a concept by allowing them to test their understanding a la "I think doing X will make change Y", then doing X and comparing what really happened to their expectation.

I think something that is embedded in the docs, like ipywidgets or pyodide, would be the best solution. It means the docs don't depend on an additional service (availability is the product of the individual uptimes, so more services almost always means lower availability) and there are no data protection questions that need answering (to directly embed many social sharing widgets or YouTube content you need understand the privacy/regulatory implications).

An approach other projects take is to link out to other community maintained blog posts, examples and tutorials. Maybe this is a model for these examples as well? It makes it clear to the reader that they are not maintained by the project itself, but somehow noteworthy because they are linked to. It does make it harder to detect that they have drifted from what the docs describe/broken :-/

I'd invest in pyodide, maybe by starting with examples that don't lead to errors. My assumption being that in the examples you'd not necessarily give people a full shell/editor experience but something graphical as in the examples above. So you can constrain users to the part of scikit-learn that works.

---

Another example are the demos on https://spacy.io/. They are code based and rely on an additional service (mybinder.org). Spacy seem happy with this setup, but see my comment above regarding "availability is the product of the individual uptimes".

Labels: Documentation, RFC