latest version of this page: https://jupyterlab.readthedocs.io/en/latest/developer/extension_dev.html
import { ReactWidget } from '@jupyterlab/apputils';
I am running jupyterlab inside a docker container, where I pre-install jupyterlab and all of the extensions as root user. When I run the docker container, I am running as a different user. In this case, the extensions fail to load in jupyterlab because the NPM cache folder is read-only for the current user, with "[...] are not valid NPM packages."
This is actually happening because jupyterlab calls "npm pack" on the extensions, requiring r/w access to the cache. If I chmod the cache first, everything works.
Is there a way to run jupyterlab where this wouldn't be an issue, i.e. it doesn't require r/w access to the original npm cache (that is owned by root on my system)?
Thanks for all the quick replies btw, y'all are awesome!
Question regarding handleComms based on #6929. Suppose the following scenario:
- Two instances (
widget-1, widget-2) of the same widgets are created (e.g. console), each with a different session pointing to two different kernels - Change one of the widget (
widget-1) to use the session ofwidget-2. This closes all comms that was registered bywidget-1since the new kernelconnection does nothandleCommsso theregisterCommTargetcall will be fenced by an if statement.
My question is suppose I want the kernel to talk to the two widgets (now connected to the same kernel) either simultaenously or independently of each other, how would I send data over since widget-2 now has no Comm associated with it?
widget-1 to handleComms to keep both comms open?
Hi everyone, I'm running into an issue with extensions that I was hoping someone has a suggestion.
I am running jupyterlab inside a docker container, where I pre-install jupyterlab and all of the extensions as root user. When I run the docker container, I am running as a different user. In this case, the extensions fail to load in jupyterlab because the NPM cache folder is read-only for the current user, with "[...] are not valid NPM packages."
This is actually happening because jupyterlab calls "npm pack" on the extensions, requiring r/w access to the cache. If I chmod the cache first, everything works.
Is there a way to run jupyterlab where this wouldn't be an issue, i.e. it doesn't require r/w access to the original npm cache (that is owned by root on my system)?
@mc-allen have you tried install nodejs within a conda environment? if you have r/w access to the conda/envs dir then you should be fine in that case
package.json and run yarn why <foo> in the <app>/staging directory.
Or should I force the new KernelConnection associated with widget-1 to handleComms to keep both comms open?
@TK-21st - right now, you'd have to explicitly force the new kernel connection to handle comms. Just be aware that there can be subtle problems with using the same comm from two different clients, where, for example, one client may shut down a comm the other client is using.
For example, if client A has a specific comm handler registered, but client B does not, a message to open a comm for that comm handler will open the object in client A, but the spec demands that client B close the comm channel, which shuts down the comm object in the kernel. No notification is sent to client A about the closure, so the result is that client A has a comm channel to nowhere
@jasongrout Thanks for the clarification, I got it to work by forcing handleComms = true. I do understand the potential issues that come with that, could you may suggest a better alternative if two clients are to share a kernel?
Previously this was done by re-routing the content of commMsg callback to the new client in browser. But then it's not immediately clear to me how the client with the comm can know which other client to route the data to. Or similarly, how the new client knows where to get data from in run-time
TypeError: request to http://localhost/api/kernels?1590921821770 failed, reason: connect ECONNREFUSED 127.0.0.1:80FetchError: request to http://localhost/api/kernels?1590921821770 failed, reason: connect ECONNREFUSED 127.0.0.1:80 - I find strange that the server is launched on port 80 (should not be possible for non root user) - Tried as root but I receive anyway the same error.