Can jp_proxy_widget be installed without install

[gbrault]

Hello,

@Aaron-Watters :

I see that "newer widgets" don't need to be installed, no jupyter labextension install ... is needed Could jp_proxy_widget implement this feature?

Thanks

[AaronWatters]

Sorry for the delay. I just tested this. At present I think you only need to do a "labextension install".

Here is the history of my test just now (cleaned up a bit):

  $  conda create -n testlab python=3.9
  $  conda activate testlab
  $  conda install jupyter
  $  cd ~
  $  conda install -c conda-forge jupyterlab
  $  jupyter lab
  $   pip install jp_proxy_widget

At this point I think proxy widgets work in classic notebook but not lab.

To make them work in lab at present you need:

  $  jupyter labextension install jp_proxy_widget
  $ jupyter lab

The jupyterlab build process is mysterious and frightening to me. Do you have any additional information on how to make the "labextension install" automatic?

I will keep looking....

[AaronWatters]

This commit from jupyter-leaflet seems relevant, but I really don't understand what it is doing. Please let me know if you find any documentation on this.

https://github.com/ellisonbg/ipyleaflet/commit/31b6d8caf540c8e88759b88e2d2e520ce275e951

[gbrault]

@AaronWatters you could ask support to Martin Renou or Jérémy Tuloup, those two are working a lot on the ipywidgets. It's Martin who told me about this new capability to release widgets without install. I don't know how we can invite another Github member to a discussion, I would have done it!

Both also work at Quantstack (Sylvain Corlay company)

[gbrault]

The jupyterlab build process is mysterious and frightening to me.

@AaronWatters : you are not alone!

[gbrault]

Reason why your widget is very handy! @AaronWatters

[gbrault]

You could also go and see: widget-cookiecutter. This is a template for cookiecutter, maintained by Martin Renou to start building a new widget (ipywidgets). I would assume it is up-to-date. There is also another version for Typescript based ts based

[psychemedia]

I spent a really miserable time trying to build a jupyterlab extension, and thought I'd made sensible notes at the time, but looking back at them, I'm not convinced they're as useful as I'd hoped they'd be:-(

https://blog.ouseful.info/2022/04/12/notes-on-the-jupyterlab-notebook-html-dom-model-part-8-5-a-reproducible-development-process/ https://blog.ouseful.info/2022/04/12/notes-on-the-jupyterlab-notebook-html-dom-model-part-9-building-and-distributing-a-pre-built-extension/

[psychemedia]

Hmmm... Looking at my own automation route ( https://github.com/innovationOUtside/jupyterlab_empinken_extension/blob/main/.github/workflows/pypi-extension.yaml ) it looks like you can get away with:

python3 -m pip install build
python3 -m build

and then the wheel is in dist/ as jp_proxy_widget-1.0.10-py2.py3-none-any.whl and jp_proxy_widget-1.0.10.tar.gz ?

[psychemedia]

In passing, the Binder demo appears to be broken again; Binder now launches into JupyterLab, and somewhere along the way, jp_proxy_widget appears to have broken in Lab again.

It'd be so useful if someone with core JuptyerLab devskills could maintain this project. It's the only way most of us have any chance of wrapping js in an ipywidgets context. (It'd be really useful to be able to compare to a simple jp_proxy_widget wrapped html/js app with a "native" ipywidget version. There would then be a tutorial pathway of a sort from wrapping a pre-existing js app to creating a native one. I've tried to make sense of ipyleaflet, but really can't fathom it...)

[gbrault]

Hello @psychemedia , could you please provide a link to the binder demo you are making reference?

[psychemedia]

I clicked the link in the README to this repo... : https://mybinder.org/v2/gh/AaronWatters/jp_proxy_widget/master

[gbrault]

It works on my side @psychemedia . What is the problem you are seing?

[psychemedia]

Hmmm...

In Chrome — just getting a blank screen:

But works in Firefox...?

Okay... so... quick check: seems that Ghostery was blocking it in Chrome unless the site was trusted? My apologies for not checking that before. I seem to recall similar issues with other extensions over the years...

[gbrault]

Chrome

[gbrault]

Firefox

[gbrault]

Chrome: Version 103.0.5060.134 Firefox: 102.0.1 both 64 bits

[psychemedia]

My Issue seemed to be Ghostery.

[AaronWatters]

FWIW I just tested using the public binder and it works for me.

Am I testing the wrong issue?

[AaronWatters]

Looking at this issue again.

It looks like you can avoid

jupyterlab extension install ...

if you add build hooks that copy magic generated files into magic file system locations at the right time. This strikes me as extremely fragile and likely to break when the enviroment changes (based on previous experience with things like this).

Is there a use case that makes avoiding extension install imperative/important? Or is this just a "nice to have" kind of thing?

[gbrault]

Hello @AaronWatters , I am using docker stacks to deploy the solutions I am creating for my customers. As I have more and more applications around, I am looking at components for which install and environment is minimal. Some of the machine I am using have also limited resources (2GO RAM or even 1GO). To do the build, I have to install Nodejs on those machine as well As I tend to use your component in every of my applications, for me, it's not nice to have.

My major use case is to use your component as a communication channel to/from python/js and it's very simple to use and quite reliable. Thanks again for your solution!

[AaronWatters]

I think you will need NodeJS to build jp_proxy_widgets whether or not you use extension install. In either case the javascript package must be reconstructed.

I don't see how avoiding extension install reduces the resource requirements. It obviously simplifies the build procedure, of course.

I'll take your word for it, but the details are not clear to me.

[gbrault]

I understand @AaronWatters : it's a matter of simplification, in that sense it's not mandatory to deploy the application: it's just more simple.

Concerning resources, I experience big requirements in some cases above all in RAM, with less than 2GO, you can get into trouble. I have small application which would require just 1GO VPS and working fine with minimal install constraints.

I even was able to deploy Jupyter lab on RPI A+ (512MO RAM), but as soon as you want to build, it does not work! (its not in my deployment targets for the apps we are talking about)

But I agree that it is not simple task to have this jp_proxy_widgets with no installation as specifications for (ipy)widgets is not always cristal clear.

[AaronWatters]

@gbrault -- if you want a connector between javascript and python you should look at https://github.com/AaronWatters/H5Gizmos which doesn't depend on Jupyter at all (but works in Jupyter). I built it partially to avoid the complexities of the Jupyter environment.

[gbrault]

@AaronWatters I will give it a try

[psychemedia]

I just spotted this migration utility which may help with upgrading this extension to a v3 extension that I think doens't need the explicit/manual installation step? https://jupyterlab.readthedocs.io/en/stable/extension/extension_migration.html#jupyterlab-2-x-to-3-x