Support remote server being treated like a 'local' server when on same machine as VS code extension host

[lasergyro]

Current Working Directory is not the current notebook directory.

This goes against default behaviour in jupyter notebook and jupyter lab.

Can this be fixed? If not, how can I automate setting the current work directory to the file location? Is there some environment variable that is set to the current notebook file that I can read in a setup cell?

Environment data

• VS Code version: 1.61.1
• Jupyter Extension version (available under the Extensions sidebar): v2021.9.1101343141
• Python Extension version (available under the Extensions sidebar): v2021.10.1336267007
• OS (Windows | Mac | Linux distro) and version: Windows 21H1
• Python and/or Anaconda version: 3.9
• Type of virtual environment used (N/A | venv | virtualenv | conda | ...): conda
• Jupyter server running: Remote

Expected behaviour

from pathlib import Path; Path.cwd() returns the directory where the current notebook is.

Actual behaviour

The directory where the jupyter remote server was started is returned.

Steps to reproduce:

1. Externally, start jupyter server at ~
2. Create folder at ~/a
3. Create folder at ~/a/b
4. With vscode remote ssh, open ~/a.
5. Run vscode command to create notebook at ~/a/b/c.ipynb
6. In the notebook, run from pathlib import Path; Path.cwd()

[rchiodo]

Thanks for the bug. We don't currently control the path where you start the remote server. A kernel from the remote server will default to that path when starting.

You can either:

• Start the jupyter server at a different location
• Change the directory in a cell
• Not use a remote server (remote ssh is supported by the jupyter extension). If you just use 'Default' on this picker here:

VS code will start the 'remote' server on the box itself. It will then use this setting when starting the kernel:

Which should default to the same directory as the notebook.

[lasergyro]

I already have jupyter:notebook file root set to ${fileDirname} .
It does not solve my issue which will be common to any jupyter user coming to vscode.

The default use case is that a jupyter server is used to open multiple kernels. One per notebook.

Therefore the common use-case of having a remote server is not solved by defaulting to the server root directory for the notebook working directory.

It is also not common to anyone using jupyter for work to have a flat directory structure; a common gripe to newcomers to jupyter is starting the server at some folder and then wanting to access some notebook above, to which the common solution is to start it in the home directory.

This bug is not solved. vscode starts the kernel, has access to the root folder of the server, so it could do initial setup to change directory to the notebook's, as jupyter does, and thus make it more usable to most jupyter users.

[rchiodo]

In the remote server case where you're using remote ssh, the fact that your remote server and VS code are running on the same machine is a coincidence. Normally when connecting to a remote server, the machine is not in the same place as your code.

We don't know the directory structure of the remote machine for remote servers so we can't force the ${fileDirname} on the kernel when launching. The ${fileDirname} is for the 'local' machine.

That's why I recommend you just let us create the jupyter server. Then we know the kernel is on the same machine that the VS code extension host is running at.

[rchiodo]

This might explain it better

https://code.visualstudio.com/docs/remote/ssh

In the diagram at the top, your 'remote' jupyter server would be an entirely separate machine as far as we know. There's nothing to indicate to the VS code server that it is on the same machine (or started from the same relative directory) as the jupyter server you created.

You can see that here:
https://jupyter-server.readthedocs.io/en/latest/developers/rest-api.html#post--api-kernels

That's the API we use to start a kernel (for remote anyway). What would the CWD be?

[lasergyro]

Thanks for the clarification. It's not my 'normal' that the server is not in the same machine as the code, therefore the confusion.

…

On Wed, 20 Oct 2021, 17:54 Rich Chiodo, ***@***.***> wrote: In the remote server case where you're using remote ssh, the fact that your remote server and VS code are running on the same machine is a coincidence. Normally when connecting to a remote server, the machine is not in the same place as your code. We don't know the directory structure of the remote machine for remote servers so we can't force the ${fileDirname} on the kernel when launching. The ${fileDirname} is for the 'local' machine. That's why I recommend you just let us create the jupyter server. Then we know the kernel is on the same machine that the VS code extension host is running at. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#7976 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHUB3OSTC4GAEN3TE6TFPB3UH3X5RANCNFSM5GLH6QYA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[lasergyro]

I think both cases could be handled: if remote ssh is currently being used, and the path of the notebook file is a subpath of the remote jupyter server, then set the cwd to the relative path from the server to the notebook.
Ah, except you can't get the root path of the server.

[rchiodo]

This is the hard part:

then set the cwd to the relative path from the server to the notebook

What's the path that the server started at? We could potentially get cwd from the active jupyter server by querying the process itself, but then we'd have to figure out which process is the jupyter server. Potentially we could start a dummy kernel though and have it output the cwd for us to read. But then we'd have to also make sure the machine is the same.

But since you have VS code on the same machine, there's no need to run the server yourself. You can just have us start it.

I don't think we'd do the extra work to make remote servers behave like local servers when they are on the same machine as the VS code server.

Is there a reason you want the remote server there? Maybe sharing with other people that don't use VS code?

[lasergyro]

Regarding getting the server start path: the dummy kernel would work; presumably if vscode sees the kernel file via remote ssh in the same place, then it can assume it is the same machine.

The server is remote because it places the code closer to the data.
There's a few reasons for not wanting to manage jupyter with vscode.
Having the lifecycle of VScode tied to Jupyter makes it harder to debug issues that show up in one of them ( jupyter crashes / vscode crashes / vscode ui issues ).
I am not even at 50% usage of vscode-jupyter due other issues, and that's another reason to not want vscode managing it, I often jump back to jupyterlab.
I often leave the jupyter server running while I have closed vscode, either finishing some computation or because my client machine was powered off.

[rchiodo]

I'll change this to an enhancement and see how many people up vote it.

[zpincus]

FWIW, perhaps the "real" fix here is to figure out ways to address / mitigate the substantial pain-points of using the "local" jupyter server, succinctly noted above by @lasergyro -- which keep coming up in various guises (e.g. #1378, #1654). It's ultimately these issues that cause folks like me and @lasergyro to turn to the "remote" server option even locally on the same machine vscode is running on (or that the remote-ssh extension is running on).

[TTTPOB]

is there a reason you want the remote server there? Maybe sharing with other people that don't use VS code?

for me there is just one reason:
remote sessions won't be closed when i close vscode

a job lasting for days is common for me, I can't keep my laptop connected to the server for like a few days

[DonJayamanne]

I'm closing this issue as there haven't been enough upvotes to warrant this feature requets.
Today remote servers are treated as completely remote, and trying to make it work like it was a local maching but using remotes would require a lot of changes with if conditions complicating the code.