Split the package in two

[martinRenou]

Background

Although Jupyter widgets are originally implemented in Python, it is actually a well thought system where one can implement a back-end for another language than Python. For example, a C++ back-end was created for core ipywidgets and ipyleaflet:

• https://github.com/jupyter-xeus/xwidgets
• https://github.com/jupyter-xeus/xleaflet

As of today, the way packaging is done in ipywidgets allows to only install the front-end part of ipywidgets by installing the jupyterlab-widgets package, e.g. this allows xwidgets to only depend on jupyterlab-widgets instead of the full ipywidgets package.

This is although not possible for ipyleaflet and other custom widgets libraries (the cookiecutter does not provide this setup by default).

I propose to make an attempt to split ipyleaflet into two packages:

• ipyleaflet: The Python back-end implementing all Python models
• jupyter-leaflet: The front-end package, installable through conda or pip individually, installing the proper jupyterlab and notebook (<= v6) extensions under the share/ directory.

cc. @SylvainCorlay @gjmooney @jasongrout @ibdafna

[maartenbreddels]

See also https://github.com/jupyter-widgets/ipywidgets/issues/1892

My preference is compatibility, which means pip install ipyleaflet Just works ™️. Therefore I raise you with 2, and suggest 4 packages

• ipyleaflet-kernel (or -core, only kernel/python code)
• ipyleaflet-jupyterlab / jupyterlab-leaflet (only the lab extension)
• ipyleaflet-nbextension (the old notebook extension)
• ipyleaflet (a meta package with the above as dependencies, pinned to exactly the same versions of all above packages) which provides the compatibility / Just works ™️ feature.

If we automate this with CI, and also do a conda-forge recipe with multiple outputs like Solara: https://github.com/conda-forge/solara-feedstock/ it does not require much work. I also suggest we pin everything to the exact same version, and release everything together even if there are no changes.

[martinRenou]

That sounds good to me!

Also keeping everything in a single repo may be the easiest, similar to what we do in ipywidgets.

I also suggest we pin everything to the exact same version

I'm not 100% in agreement with this though, although I don't have a strong opinion on it.

If ipyleaflet-kernel makes a breaking change in the Python API, I don't see a reason why ipyleaflet-jupyterlab should get a major release, though the ipyleaflet meta package should.

Counter argument is that it may be easier to setup e.g. jupyter-releaser if we keep the same version for everything.

[maartenbreddels]

Yes, easier and simpler. I really like the way many of our repos are setup, we just run ./release.sh minor and don't need to think about what may have broken on the js or py side, and which version should be bumped.

It's a slight overhead for pypi, but storage is cheap, developer mental energy is not :)

[martinRenou]

Versioning was too tricky with ipyleaflet-core in the way, I'm removing it in https://github.com/jupyter-widgets/ipyleaflet/pull/1189 and making a release.

I believe ipyleaflet-core brings unneeded complexity and two packages is enough.

[martinRenou]

Happy to continue discussing this though. I just want a release out for now, without struggling too much.