Connecting VSCode to the TNG Lab for remote analysis
Dylan Nelson
26 Aug '23
Instead of using the web browser based JupyterLab interface, you can also use VSCode, if that is now your preferred way of working.
You can connect VSCode running on your computer to your remote Lab. This lets you develop your code/notebook as you normally would in VSCode, but code will execute on the remote server with direct access to the simulation data. This is a two step process: (i) create an API token on your Lab as shown above, (ii) in the VSCode command palette, select 'Jupyter: New Jupyter Notebook'. Then, under 'Select Kernel' (upper right), choose 'Existing Jupyter Server...' and enter the URL as https://data-eu.tng-project.org/lab/user/{email_address}/?token={api_token}. Then you can select any available kernel, such as Python 3.
Xingyao Cai
26 Aug '23
Dear Dylan:
Thank you so much, Dylan, for making this upgrade and allowing access to VSCode! I really appreciate your efforts in enhancing our workflow. Personally, I find working in VSCode much more efficient due to the various productivity plugins I use, so having this option is fantastic.
I remember asking you about the possibility of using VSCode before, and I'm thrilled to see that it's now a reality. Being able to access data within my familiar coding environment is a huge help.
I'd also like to share a quick tip for anyone looking to connect to TNG's Jupyter kernel through this method. It's important to ensure that your local Python environment has the 'jupyter_server' package installed. If you've set up Jupyter through VSCode, it often installs 'ipykernel' package but might lack 'jupyter_server' package. I encountered a similar issue when trying to connect to the server. My notebook displayed a [warn] error and the message 'Error occurred while trying to start the kernel, options.disableUI=false Error: Server handle not in the list of known handles.' However, after running 'conda install jupyter_server', everything worked seamlessly, and I was able to compile and run my local code using the server's kernel.
Once again, Dylan, a big thank you for maintaining the server and providing such valuable improvements.
Instead of using the web browser based JupyterLab interface, you can also use VSCode, if that is now your preferred way of working.
You can connect VSCode running on your computer to your remote Lab. This lets you develop your code/notebook as you normally would in VSCode, but code will execute on the remote server with direct access to the simulation data. This is a two step process: (i) create an API token on your Lab as shown above, (ii) in the VSCode command palette, select 'Jupyter: New Jupyter Notebook'. Then, under 'Select Kernel' (upper right), choose 'Existing Jupyter Server...' and enter the URL as
https://data-eu.tng-project.org/lab/user/{email_address}/?token={api_token}. Then you can select any available kernel, such as Python 3.Dear Dylan:
Thank you so much, Dylan, for making this upgrade and allowing access to VSCode! I really appreciate your efforts in enhancing our workflow. Personally, I find working in VSCode much more efficient due to the various productivity plugins I use, so having this option is fantastic.
I remember asking you about the possibility of using VSCode before, and I'm thrilled to see that it's now a reality. Being able to access data within my familiar coding environment is a huge help.
I'd also like to share a quick tip for anyone looking to connect to TNG's Jupyter kernel through this method. It's important to ensure that your local Python environment has the 'jupyter_server' package installed. If you've set up Jupyter through VSCode, it often installs 'ipykernel' package but might lack 'jupyter_server' package. I encountered a similar issue when trying to connect to the server. My notebook displayed a [warn] error and the message 'Error occurred while trying to start the kernel, options.disableUI=false Error: Server handle not in the list of known handles.' However, after running 'conda install jupyter_server', everything worked seamlessly, and I was able to compile and run my local code using the server's kernel.
Once again, Dylan, a big thank you for maintaining the server and providing such valuable improvements.