Semi-official community widgets

[pbugnion]

Summary

I'm suggesting developing semi-official widgets that live in the 'jupyter-widgets' organisation. These would be widgets -- like a code-editor widget -- that are building blocks for other widgets, but are too big to fit in the core package.

Discussion

In issue #1665, Jason mentioned that he wants to keep the set of core widgets small. They should mostly be small wrappers around DOM elements. I completely agree with the rationale behind this decision.

We also get many requests for what one might call 'building-block' widgets that are more complex than just a wrapper around a DOM element, but not sufficiently flashy that they would get the sort of attention that widgets like ipyvolume or bqplot enjoy. Typical examples might include:

• a code editor widget (issue Syntax highlighting in TextArea widget #1665).
• a wrapper around Select2
• a JQuery UI based date picker (since the one in controls only works for some browsers)
• a table layout widget for laying widgets out in a table (issue Ability to set border edges independently #920)

I think that there's not very much incentive for individuals to write these unless they are very easily discoverable. If, say, I'm a member of the community with little access to the core devs and I try to write a code editor widget, I would be worried that nobody would use my widget because I don't really know how to make people discover it.

Coming at it from the other side -- if I'm developing a high-level widget that needs to embed a code editor (e.g. I'm writing a widget to interact with SQL databases), I might feel that the risk of relying on a third-party widget editor that has no official support would be too great. What if the code editor becomes unmaintained?

I think that we can answer these concerns with a set of community widgets that are developed by the core widgets devs. To make them 'semi-official', and to avoid them becoming unmaintained, they could live in the jupyter-widgets organisation.

[maartenbreddels]

Yes, this has been going through my mind as well. I agree with @jasongrout that the core should be minimal, but there will be a need for what you describe. The most difficult questions as always, is the name 😉 .
Apart from the name, I am a bit worried about maintenance, and if it's part of the jupyter-widgets organisation how possibly bad maintenance would reflect on ipywidgets. I do think, in order to get more popularity/traction, we need more widgets like the ones your describe: not fully core, too small to be standalone.

[jasongrout]

I think that we can answer these concerns with a set of community widgets that are developed by the core widgets devs. To make them 'semi-official', and to avoid them becoming unmaintained, they could live in the jupyter-widgets organisation.

I like the idea of some more advanced widgets developed separately from the core widgets. Of course, making the repo in jupyter-widgets does not automatically make them maintained - there still needs to be someone willing to maintain them. If you as a core widgets developer want to develop one of these more advanced widgets and commit to maintaining it, then definitely, please create a repo in the jupyter-widgets org and go for it!

In general, though, it sounds like it's a discoverability problem we need to solve? There are probably more effective ways to do this than just making the repo in the jupyter-widgets org.

[maartenbreddels]

In general, though, it sounds like it's a discoverability problem we need to solve? There are probably more effective ways to do this than just making the repo in the jupyter-widgets org.

Are you thinking of something that lives in the @jupyter-widgets npm scope, and also lives in this repo?

[vidartf]

In terms of easing discovery, we could make a JupyterLab plugin that:

• Presents a list of widget libraries from various (extensible) sources. E.g. all NPM packages with a certain tag/keyword (jupyter-widgets?). And/or from conda(-forge) / PyPI.
• Shows meta info. E.g. version, last release date, but also it could maybe gray out any extensions that are not version compatible with the current install.
• Will allow you to attempt to install these directly from within lab (tricky for those that need a server extension as well), but python / jlab dependencies should be solved automatically (I think?). There might be a need for some metadata to establish kernel-frontend package dependencies to have this work.

I had some discussion with @blink1073 at JupyterCon about having similar discovery/installation for general jupyterlab plugins as well, so there might be possibilities for re-using quite a bit of code across projects here.

I'll have to defer to others (jupyterlab devs) on how feasible this is though.

[pbugnion]

Maintenance is definitely a concern and, if a widget that's part of the jupyter-widgets organisation becomes unmaintained, it reflects badly on the core package, as @maartenbreddels mentioned.

If you as a core widgets developer want to develop one of these more advanced widgets and commit to maintaining it

I'd definitely like to build some of these widgets, but I worry about sustainability.

In general, though, it sounds like it's a discoverability problem we need to solve

I think that you're right -- discoverability is the real problem. Putting widgets in the jupyter-widgets organisation helps just for those widgets, but it doesn't solve the root cause.

Are you thinking of something that lives in the @jupyter-widgets npm scope

I hadn't even really considered the NPM scope, but that's a good point. I don't have strong feelings on NPM scope.

and also lives in this repo?

I was thinking in a different repo in this organisation, to decouple the development cycle of core widgets and 'semi-official' widgets.

[pbugnion]

A 'package manager' for widgets and extensions seems like a great idea, but a lot of work. Maybe an incremental first step is updating the list of community widgets on jupyter.org and having a process for authors to submit new widgets to that page?

[jasongrout]

We had our first contribution to that page a few days ago: jupyter/jupyter.github.io#239

[pbugnion]

Ah great! Is the preferred route for adding new widgets to that page via a pull request?

[jasongrout]

Ah great! Is the preferred route for adding new widgets to that page via a pull request?

Yes.

[AbdealiLoKo]

I think that having a repo called ipywidgets-contrib would be a great addition here. Where such things can be contributed and unmaintained at any point of time.

[sfluo]

does this end somewhere? can a Textarea extend from Cell as it already have CodeEditorWrapper?

[jasongrout]

You could make one, though you might just use codemirror directly

[sfluo]

yeah, but have hard time to make it fully works.

[sfluo]

from IPython.display import HTML
HTML("""

<script> var editor = CodeMirror.fromTextArea(document.getElementById('code'), { mode: 'text/x-sql', lineNumbers: true, matchBrackets : true, autofocus: true, readonly: true }); </script> <textarea name="code" id="code"> SELECT * FROM recording.president_speach WHERE date = '2019-03-12' </textarea>

@jasongrout do you know
Why this code only shows line number but not other hightlights like SQL keywords ?

[vidartf]

Note that there is currently an "experimental extension manager in JupyterLab. That could possibly be built further upon to add e.g. categories like widget packages, MIME renderers etc. That could help a lot with discoverability, although that list is not curated in any way.