Transfer jupyterlab-dynext to the JupyterLab org

[jasongrout]

We'd like to transfer https://github.com/wolfv/jupyterlab-dynext to the JupyterLab organization. I volunteer to maintain this extension. This extension came out of a collaboration between @wolfv and myself several years ago.

This extension enables users to easily write and register short plugins directly in JupyterLab, load plugins from the web, and store plugins in their settings that can be automatically registered at startup. This goes a long way toward helping users quickly and easily customize JupyterLab without needing to build and publish a big package (see the long well-written post on the subject by a long-time community member @psychemedia, for example: https://github.com/jupyterlab/jupyterlab/issues/11075)

This extension is currently working with JupyterLab 3.x as a prebuilt extension. It is not currently published (and I'd like to find a more descriptive and approachable name before publishing, such as Plugin Playground or something).

This extension does use some private methods in Lumino and JupyterLab to have the dynamic registration. For example, requirements of a plugin are specified as strings, i.e., plugin ids, and we map those plugin ids to the plugins themselves using internal APIs. We did not see a way around that, and we think the benefits are well worth the hidden access to internal APIs. The plugin also currently loads RequireJS on the page to allow for loading plugins that use AMD modules (for example, dynamically registering an ipywidget from its AMD module). In the future, it would be great if we could also support webpack module federation bundles, etc.

Here it is in action, using its "Load Current File as Extension" command to register and activate plugin from the JLab text editor:

[jasongrout]

Here are some thoughts about a new name for the plugin (from https://github.com/wolfv/jupyterlab-dynext/issues/4)

• @jupyterlab/plugineditor
• @jupyterlab/pluginplayground
• @jupyterlab/pluginstudio
• @jupyterlab/pluginsnippet
• @jupyterlab/pluginfiddle
• @jupyterlab/pluginnotepad

[jtpio]

Thanks @jasongrout and @wolfv!

Big :+1: for transferring this repo to the jupyterlab organization.

it would be great if we could also support webpack module federation bundles, etc.

That would indeed be great. With this in place, the workflow could simply be about editing the .js file in JupyterLab and reloading the page. There would also not be the need to access Lumino internals, since the extension would be loaded on page refresh like the other prebuilt extensions.

@jupyterlab/plugineditor

This one sounds good.

[fcollonval]

@jasongrout I have a question regarding the opened issue on JLab: Add ability to load dynamic extensions #8866 . If that issue were to be solved. Will this extension still be needed?

[krassowski]

The same question but a different angle: do we need it to be a separate extension, or could it get merged straight into the JupyterLab core repository? If the goal is to make the start simpler, to lower the entry barrier, maybe not having to install an extension would make a better UX?

[jasongrout]

I would like to experiment with this first in an extension, which can iterate faster than in core, but yes, I think eventually it would be great to be in core.

[jasongrout]

@jasongrout I have a question regarding the opened issue on JLab: Add ability to load dynamic extensions #8866 . If that issue were to be solved. Will this extension still be needed?

Yes. That is more about exposing an API, this is about a user interface. If that issue were resolved, then we wouldn't need to do some of the hacky workarounds we do in this extension, though.

[fcollonval]

Thanks for the answer :+1: to migrate it too.

[ellisonbg]

Ohh nice, I hadn't seen this. I am fine with this being in the JupyterLab org to better enable more people to explore this direction.

On Mon, Sep 20, 2021 at 6:59 AM Frédéric Collonval @.***> wrote:

Thanks for the answer 👍 to migrate it too.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/team-compass/issues/129#issuecomment-922953423, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGXUFCTORJVDYU6Y4GCXLUC4425ANCNFSM5EJOTEGQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Brian E. Granger

Principal Technical Program Manager, AWS AI Platform @.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[wolfv]

Thanks for starting this discussion and the friendly feedback :)

I like jupyterlab-pluginplayground as it makes it seem less "serious", but I'd also be fine with jupyterlab-editor or anything else you guys prefer.

@jasongrout happy to take the necessary steps for the transfer, just let me know what to do!

[jasongrout]

I also like Plugin Playground with the current limitations, because it is pretty explicitly scoped as a simple thing to iterate on small ideas (single file, no imports, etc.). To me, it's much more like a jsfiddle or the Typescript playground than a full-blown editor for arbitrarily complex plugins. I think of it as playing around with ideas for extensions and the JLab api, and if an idea gets too large, then it's probably time to level up to a full-blown extension. But it fills the important role of being approachable and easy to experiment with, i.e., to play with.

Like Wolf, I also like how "playground" sounds more approachable and fun than "editor" :).

[jasongrout]

Another precedent for "playground" is Swift Playgrounds.

[ellisonbg]

I think the "playground" themed names for this work well

On Mon, Sep 20, 2021 at 11:49 AM Jason Grout @.***> wrote:

Another precedent for "playground" is Swift Playgrounds https://www.apple.com/swift/playgrounds/.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jupyterlab/team-compass/issues/129#issuecomment-923187246, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAGXUCTHV7TWWDCG7XIAG3UC56Z5ANCNFSM5EJOTEGQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

-- Brian E. Granger

Principal Technical Program Manager, AWS AI Platform @.***) On Leave - Professor of Physics and Data Science, Cal Poly @ellisonbg on GitHub

[psychemedia]

To me a playground is something that tends to have templated options for trying things out, such as API calls where the user changes a parameter value in a predefined function call. This feels to me to be at a lower level than that, something more like a jupyterlab-extension-direct.

For example if I wanted to create a simple extension to change cell color based on cell tag, I might be able to do that from a UI that provided playground steps of:

a) iterating over cell metadata (and allowing me to set a path to a specific piece of metadata, such as cell.metadata.tags); b) providing a JavaScript hook that takes the retrieved metadata as an argument and lets me do something to it; c) a button that squirts the necessary code into the JupyterLab UI as a running extension

but I don't see how to do that directly from this extension even though it may be obvious to someone coming from the JupyterLab developer side how this simplifies creating such an extension by allowing you to directly install and trigger a js package (from somewhere... a novice will probably develop from a local file) into the JupyterLab UI.

In trying to get a sense of the name, I'm also trying to clarify how dynext complements something like jp_proxy_widget which is another not-really-a-playground (the proxy name seems eminently sensible to me in this case).

It seems to me (and I may well be completely misunderstanding it!) that dynlab simplifies preloading code already written as a JupyterLab extension (eg with js code that perhaps makes calls onto JupyterLab framework calls), whereas jp_proxy_widget is at the higher level or wrapping an arbitrary third party javascript widget as a (loaded) ipywidget and providing hooks that let you access elements and state associated with that widget. (I appreciate the distinction between developing JupyterLab extensions as something agnostic to the kernel and purely related to hacking the JupyerLab UI, rather than extensions like jp_proxy_widget that run from a particular kernel and provide a way of interacting with UI elements rendered by the JuptyerLab machinery; but from a naive user perspective without an understanding of the architecture, it can sometimes be hard to clearly distinguish what is responsible for doing what, and how.)

For this reason, direct seems more appropriate: I think it simplifies the development process for someone who wants a quick hack around a build process, rather than providing a playground for someone who doesn't speak JupyterLab framework.

[jasongrout]

I think we could add some nice guided examples, in the vein of the Typescript Playground's examples menu: https://www.typescriptlang.org/play. That would be progress towards a more approachable, guided experience.

[vidartf]

👍 on moving, and then merging into core when more mature. Should help reduce the overhead in extension development, and should also be useful in loading extensions from CDNs.

[wolfv]

I may be completely out of the loop but I wouldn't understand what a jupyterlab-extension-direct does.

Maybe we can find a middle ground by playing on the popular "JSFiddle" which is very similar to this:

jupyterlab-extensions-fiddle or jupyterlab-extfiddle?

https://jsfiddle.net/

[afshin]

Thank you for this! 👍 from me

[jtpio]

This issue has been opened for 19 days and the feedback has been very positive so far.

Let's proceed with the move to the jupyterlab organization?

[jasongrout]

Let's proceed with the move to the jupyterlab organization?

+1. Wolf, let's coordinate a time to do this offline.

After thinking about this more, I'm still +1 on changing the name to Plugin Playground. I think Tony has some great ideas for future development for a more structured experience, and I think calling it a playground makes it much more approachable and, well, playful like Wolf says. Even if right now it is more of a sandlot without any playground structures :).

[jtpio]

Closing as the repo has now been moved to the jupyterlab organization: https://github.com/jupyterlab/jupyterlab-pluginplayground

Thanks all!