Hey all,
I built a jupyterlab extension which adds a separate Main Menu extension point (JupyterFrontEndPlugin) which a user can click and server sends a curl request followed by getting a response back. I have the response back from server but trying to set it to an environment variable within the kernel (so that I can use it within the kernel). Does anyone have any pointers on how to make that happen?
I tried it but donât see the var in notebook kernel. I am trying to access that within my python kernel
Btw are server extension env variables expected to show up in notebook as well? I thought that wasnât the case.
Perhaps try printing sys.path in the GET handler and in the Notebook in order to determine if the Notebook kernel is the same as the one executing the GET handler.
@adpatter Looks like the variables are present in the kernel but not directly after triggering the extension. I need to restart the kernel and run the cells again to get the env value (every time I trigger the extension, I need to restart the kernel). I am guessing once I am restarting the kernel itâs picking up the env variables from server.
sys.path looks the same for kernel as well as for the handler.
Wondering if you had to do something similar or they were getting updated as soon as the extension was triggered?
I started jupyter lab at the command prompt and then opened a Notebook and printed the variable. As such, perhaps I was starting the kernel for the Notebook after the extension had started.
If your extension is on GitHub, please send a link and I will take a look at it.
I would not expect to be able to set environment variables from a server-extension and read them in a kernel. This is fragile for a couple of reasons:
some user kernels run remotely
some users change how local kernels are spawned (e.g. using a pre-populated pool)
Additionally, even kernels launched from the same process do not share the same environment as the parent; child processes only use the parent process environment as a template from which their own (independent) environment is constructed.
If you just want a UI that integrates with a kernel, a âsimpleâ way to do this is to create a custom widget (or use ipywidgets). This effectively permits you to put the business logic in the kernel process, and just have the UI controls operate at the frontend-layer.
If, however, you need / want to integrate with JupyterLab as a frontend extension, then you could look into a client-server model. In this design, the serverextension implements a socket interface that running kernel(s) can talk to. You could similarly use a shared-file to communicate between the server extension and the kernel, but this introduces the need to lock things, which is best avoided unless essential. This will not work for the case that kernels are running on a separate machine, but that might not be a problem.
Without more information about what youâre planning to do here, itâs hard to provide any more detailed suggestions. Perhaps you could expand on what you want to achieve?
Thanks for the response @agoose77 and @adpatter. I will move my extension on Github later today.
Good to know that setting env variables server side and reading them in kernel is not super stable.
Overview of what I am trying to do here - I built a frontend extension (added a separate menu option) which once the user clicks on, sends a request to a separate service and gets a value back. Now I have the value available within my TS code but wanted to make it available within the kernel.
You mentioned the serverextension has a socket interface which the kernel can talk to, is there a documentation for this? Using this I can potentially query serverextension from kernel to get the value back (and donât have to go through ENV route).
Hey @aish
Can you give an update on how you solved this issue?
I am also looking into setting up the kernel environment based on the settings of a jupyter lab extension
@pll_llq hey, I ended up using a shared filesystem (you can write to a common path, e.g. â/tmp/file.txtâ from within the server which can be read by the kernel as well. Not sure what your use cases is but you might have to take care of locking in case of multiple kernels trying to write stuff and so on