Bundle extension examples in PyPI installs

[MUFFANUJ]

closes #88

This PR makes the bundled extension-examples available when jupyterlab-plugin-playground is installed from a built package, including the PyPI path. Instead of asking users to manually clone the examples repository after install, the package now includes the examples and populates them automatically when JupyterLab starts, so the examples are visible in the UI immediately.

This might be a better fit than “1-click fetch” for the installed-package case because it removes the extra user step entirely and does not depend on a post-install network fetch or additional setup from inside the UI. It keeps the experience simpler and more reliable for users who just install the package and expect the examples to already be there.

I tested this locally ina virtual environment.

[github-actions]

👈 Launch a Binder on branch MUFFANUJ/jupyterlab-plugin-playground/noManualClone

[krassowski]

Hmm, I like how it makes the examples "just work". I see two potential issues here:

• when a bug gets fixed in extension-examples we need to release a new version of plugin-playground to pick it up
• folks who want to use this plugin just for dynamic extensions without need for node dependencies get a much larger install bundle

We could consider publishing extension-examples to PyPI and then pulling it via optional dependencies (but then it requires user to opt-in to get examples), a meta package (like jupyter-collaboration includes multiple dependencies which can also be installed separately). But this adds a lot of overhead quickly, so I am not sure if it's worth it. Maybe, maybe not.

If we keep the approach proposed by this PR as-is, can we also drop submodule checkout step from binder/lite and centralize that in one place?

[MUFFANUJ]

Not completely. The new packaged-install path solves the PyPI case, but Binder and Lite are still source-checkout workflows. In particular, Lite needs the examples during the docs build so docs/conf.py can copy them into docs/content/extension-examples, which happens before the installed-package startup hook would run. So I do not think we can drop those steps outright.

[krassowski]

I posted on Zulip to check for dissent and ideas #jupyterlab > plugin playground to ship extension-examples in wheel

[krassowski]

Next step here could be exploring how much we can trim the extension-examples directory before shipping it as it currently contributes a lot to the bundle size. I think this covers both this copy and the one that is used to build JupyterLite deployment (for faster loading), ideally using a configuration in a single source of truth across both:

• drop .git and .github folders and other hidden files from extension-examples/ and subdirectories
• drop playwright ui-tests, there is no way to run these in the browser
• drop lockfiles as we are not installing anything
• list all remaining files and check if there is something we could compress upstream in extension-examples repo (any screenshots which are too large or not compressed with trimage/opting already?)
• anything else?

Starting point:

[MUFFANUJ]

It now removes hidden files (.git/.github), ui-tests, lockfiles, Playwright configs, build/cache folders.

[MUFFANUJ]

Should we merge this? I have excluded the images/gifs/vids and as per discussed i will update the compression workflow in the extension-examples. @krassowski

[krassowski]

Do you know what is responsible for the majority of the size? It looks like this till yields 30+ MB:

https://github.com/jupyterlab/plugin-playground/actions/runs/23755660059?pr=105

[krassowski]

If we end up with more scripts like that it would be worthwhile to put it under /scripts directory but since it is only one I think that's ok to keep as-is