Keeping this updated with @jupyterlab/services

[infinity0]

This repository depends on @jupyterlab/services version 0.35 but that repo is already on version 0.41.

What are the plans for keeping this up-to-date? That repo says "not suitable for public use" but the fact that you're relying on its typescript definitions means that you're using it as a public API, which I have to figure out how to deal with when trying to package this for Debian.

[jasongrout]

Thanks for packaging this for Debian!

@blink1073 - what is the status of the @jupyterlab/services repo? Are we close to declaring it stable now?

[infinity0]

On closer inspection, it looks like the only thing being used is Kernel and KernelMessage so for the time being I'm just bundling these definitions only with the ipywidgets Debian source package, and avoiding packaging the whole of @jupyterlab/services.

In the long run, if it's too hard to make the whole thing stable, it might be worth splitting out the "more stable" parts into another package (with fewer dependencies), and depend on that instead from ipywidgets.

[jasongrout]

@jupyterlab/services is stable or nearly stable, I think (not that it might not change in the future, but it's a very solid package right now as it is). It may be just a matter of declaring it so. Right now, we're in the process of evaluating a number of jupyterlab packages and deciding the stability of each of them.

[jasongrout]

(or rather, we're just about to the point where we'll start declaring the status of each package.)

[jasongrout]

We could also just have our own interfaces for what is passed to display_model and display_view. That's probably better anyway for arbitrary widget managers.

[blink1073]

I would not declare @jupyterlab/services to be close to stable at this point. I had intended to refactor it after we release beta to clean up the handling of server configuration.

[jasongrout]

@infinity0 - certainly the type definitions we are using are stable - they are given in the jupyter spec. @blink1073 and I were talking about maybe repackaging up those type definitions in a stable package. However, it sounds like you have a workaround for now?

[infinity0]

Yes, I have a workaround for now so this isn't too urgent. It's not a nice workaround though :p A stable package sounds good, I'd also comment further that if the spec you're talking about is formalised, it might be good for this to be one single package, rather than e.g. have @jupyterlab/services type defs vs other type defs split.