Add open in colab buttons to demos in docs and /demos

[aliabd]

Adds buttons to open a demo in colab:

Untitled.mov

If a contributor wants to change a demo in the /demo dir, they just have to run /demo/generate_notebooks.py to regenerate all the .ipynb notebooks. I could create a github action for this but seems like overkill.

Note that not all the demos will work on colab, the ones that reference another file in the dir won't work (for example). I could detect this and not show a colab button for those, but I feel like it would still be useful for a reader to be able to play with the code (so don't know if it's the right idea to skip them), and usually you can easily replace the file (I could link to the dir in github so they can move the files they need?)

Closes: #2278

Checklist:

• I have performed a self-review of my own code
• I have added a short summary of my change to the CHANGELOG.md
• My code follows the style guidelines of this project
• I have commented my code in hard-to-understand areas
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[github-actions]

All the demos for this PR have been deployed at https://huggingface.co/spaces/gradio-pr-deploys/pr-2608-all-demos

[abidlabs]

Wow this is great @aliabd! LGTM with a few suggestions on the points you raised:

If a contributor wants to change a demo in the /demo dir, they just have to run /demo/generate_notebooks.py to regenerate all the .ipynb notebooks. I could create a github action for this but seems like overkill.

I took a look at the /demo directory and we do edit it relatively frequently so I actually think it would be good to have a GitHub action to run to make sure no demos and notebooks go out of sync.

Note that not all the demos will work on colab, the ones that reference another file in the dir won't work

I think that's fine. I think it's pretty clear to users when this happens and how to fix it. As a general note, perhaps we should switch to using URLs in our demos instead as much as possible

[aliabid94]

This is great.

I think there should be a github action that opens a commit if a demo changes and the notebook hasn't.
As for demos with files in the folder, add a cell block before the demo that curls and downloads the files into the colab environment, so the paths resolve the same way.

[aliabd]

Ok I updated this:

• There's now a github check that will run on every PR that changes something in the /demo path. If the demo run.py has changed but not the generated notebook, the check fails. (check works by running python generate_notebooks.py and asserting that there's nothing to commit). You can see an example of it failing in this fake commit here, and an example of it passing once I regenerated the notebooks here.
• When the notebooks are generated, we automatically add a cell to wget the necessary files from the demo folder (and put them in the correct structure) so every demo should run immediately.

[abidlabs]

Why are we skipping "reset_components", "custom_path", "kitchen_sink_random"

[aliabd]

reset_components and kitchen_sink_random import from other demos so can't be used on colab alone. We also skip them when uploading to spaces because they don't work there either. They're only used for the PR demos. (along with all_demos)

custom_path is a demo of launching gradio using uvicorn from the terminal, so not really useful on colab either (also skipped on spaces)

[abidlabs]

Awesome PR @aliabd! Left a couple of nits above but otherwise LGTM.

One suggestion -- if the CI check fails, would it be possible to print the command that needs to be run to regenerate the notebooks?

[github-actions]

The demo notebooks don't match the run.py files. Please run this command from the root of the repo and then commit the changes:

pip install nbformat && cd demo && python generate_notebooks.py

[aliabd]

@abidlabs thanks for the suggestion. The github action will now comment on the PR if the check fails with the command that needs to be run. The last two commits show an example of this.

[github-actions]

The demo notebooks don't match the run.py files. Please run this command from the root of the repo and then commit the changes:

pip install nbformat && cd demo && python generate_notebooks.py

[freddyaboulton]

Does this run on forked repos?

[aliabd]

Good question, I just checked on this PR #2691

The check fails as expected, but it can't comment. Do you know how to fix that? Apparently it's an open issue.

[freddyaboulton]

We need to follow this approach I think: https://securitylab.github.com/research/github-actions-preventing-pwn-requests/#:~:text=The%20main%20differences%20between%20the,but%20not%20from%20external%20forks. I think it may also be possible to comment on the pr if the action is defined in a separate repo? I think that's what doc-builder does.

@pngwn May now some best practices for commenting on PRs from forks.

[aliabd]

Ah nice

[freddyaboulton]

Super cool @aliabd !

[freddyaboulton]

Just wondering why this is neccessary?

[aliabd]

Good question...

The way the github check works is by running python generate_notebooks.py and seeing if there's anything to commit. If there is, it must mean that run.py files and run.ipynb notebooks don't match.

The problem is that jupyter notebooks create a random id for every cell that's different each time, and creates a huge mess on git diffs even when the notebook is functionally the same. So everytime python generate_notebooks.py is run it will show that every notebook has changed. There's no way to set the id using nbformat so instead I just manually set them in the file from python and define a seed to make sure they're always the same.

[freddyaboulton]

Very cool - thanks for explaining!

[aliabd]

@freddyaboulton I updated this to use pull_request_target and the action now works as expected for both branches and forks. Thanks for the suggestion! Tested here in a branch and a fork.

[aliabid94]

looks great!