Merge with ipywidgets?

[mgeier]

I don't really understand why this has to be a separate download for people to worry about.

What about moving what is now jupyter_sphinx.embed_widgets into the main ipywidgets package?

There is already a dependency to that anyway.

Then users would only need to install ´ipywidgets´ (which they most likely have installed already) and include it in their conf.py, e.g. like so:

extensions = [
    'nbsphinx',
    'ipywidgets',
    'sphinx.ext.mathjax',
]

[Carreau]

I can 2 several reasons :

• it is not (yet) stable/battle tested enough ? (quick release cycle... etc)
• it is mostly to build docs, so most user of ipywidget don't need it ?

But I don't see any reasons not to in the long run .

[SylvainCorlay]

OK let me ellaborate on that:

1. From the widgets project view point:

There are already many packages in the ipywidgets repo:

• ipywidgets the python package which holds the implementation of the python models for the core widgets and the base widget.
• jupyter-js-widgets the npm package which holds the implementation of js models for the core widgets, the base widget, the base widget manager, and the embed manager.
• widgetsnbextension which holds the stable notebook extension and bundles jupyter-js-widgets with a specialization of the manager for notebook.
• jupyterlabextension which holds the lab notebook extension and bundles jupyter-js-widgets with a specialization of the manager for lab.
• jupyter-widgets-schema which holds the json schema spec for widget mime types.

We think that the lines of divide between these different packages are the right ones. ipywidgets is installed with the kernel and the other packages are installed with the notebook server.
But we should probably start splitting things into different repositories. The number of different projects in this one repo is too high.

Since the sphinx extension is a rather standalone one, it is already better to make it external. The first one to be split off after 6.0 will probably be the schema spec (widgets counterpart to nbformat).

2. From the sphinx extension view point

A common pattern we see with sphinx extension is to have multiple regrouped under a single package sphinx.ext, altair etc... There is at least another extension that I wanted to put under jupyter_sphinx.

[mgeier]

I guess the Sphinx extension has to access some JavaScript files to include them in the Sphinx output, right?
Wouldn't that be a reason to package them together?

But regardless of all those technical reasons for and against it, I think it would be much better for the user experience if users wouldn't have to select yet another package for download.
The installation of the widgets (on top of the base Jupyter installation) is already complicated enough IMHO.

@SylvainCorlay What would that other extension be?

[SylvainCorlay]

I guess the Sphinx extension has to access some JavaScript files to include them in the Sphinx output, right?
Wouldn't that be a reason to package them together?

The javascript is fetched from a cdn at the moment.

But regardless of all those technical reasons for and against it, I think it would be much better for the user experience if users wouldn't have to select yet another package for download.
The installation of the widgets (on top of the base Jupyter installation) is already complicated enough IMHO.

I think that the ipywidgets repo is already overcrowded. I would actually like to split it in a number of smaller projects with a clearer separation of concerns.

[mgeier]

The javascript is fetched from a cdn at the moment.

OK, makes sense.
Is there an option to make it available for offline use, too?
Probably similar to http://www.sphinx-doc.org/en/1.5.1/ext/math.html#confval-mathjax_path?

I'm mainly concerned about the usage of widgets together with nbsphinx, so I've created an issue there: spatialaudio/nbsphinx#84.

[SylvainCorlay]

OK, makes sense.
Is there an option to make it available for offline use, too?
Probably similar to http://www.sphinx-doc.org/en/1.5.1/ext/math.html#confval-mathjax_path?

That would make sense to me. Besides, we will probably have multiple flavors of the embedder. The one currently on the cdn deals with custom widgets by also fetching them on the cdn.

We will probably have a version of the embedder that only looks for custom widget code locally.

[SylvainCorlay]

This is because it is not a resolved matter that I did not include the script tag in nbsphinx in the PR dealing with the mime type, leaving the responsibility to the client to add more script tags. But we do need to deal with this issue.

[SylvainCorlay]

Closing this one. Will open new issues on the options to use another url for the embedder.

[mgeier]

For reference: jupyter-widgets/ipywidgets#2284