Working directory for non-python kernels in a temp directory

Bug: Notebook Editor, Interactive Window, Editor cells

Steps to cause the bug to occur

1. Create a new jupyter notebook and save it in a file location, or open an existing file
2. Change the kernel to something already installed (e.g. Julia 1.4.2 in my case)
3. Run pwd() to see the working directory

Actual behavior

I am getting C:\\Users\\MYUSERNAME\\AppData\\Local\\Temp\\7bb05f8c-bf2c-4a11-b590-de1cdae0d271 as the path.

This is especially important for Julia since the jupyter kernel activates a Project.toml and Manifest.toml local to the path of a file when it starts. This makes reproducible packages/etc. possible, and is difficult to do after startup.

Expected behavior

It should be be where the file is opened or saved. In my case, 'c:\\Users\\MYUSERNAME\\Documents\\GitHub\\sandbox'

This is what happens with python kernels, for example. In that case, ;pwd returns that string.

Your Jupyter and/or Python environment

• Jupyter server running: Local
• Extension version: 2020.6.91350
• VS Code version: 1.46.1
• Setting python.jediEnabled: false
• Python and/or Anaconda version: 3.7.4 64 bit conda
• OS: Windows
• Virtual environment: conda

Microsoft Data Science for VS Code Engineering Team: @rchiodo, @IanMatthewHuff, @DavidKutu, @DonJayamanne, @greazer, @joyceerhl

[stevengj]

Why can’t you set the working directory to that of the notebook before executing the kernel-launch command? That’s what Jupyter does…

[IanMatthewHuff]

Since the change here is in the Python extension then you would actually need the insiders version of our extension (can use that with either normal VS Code or VS Code - insiders). Info is on this here: https://github.com/microsoft/vscode-python/blob/master/CONTRIBUTING.md#development-build It’s very easy to swap that back to the release version, so it’s safe to use that to test if you want.

I believe that this should work with github codespaces, I’ve not tested that myself, but it’s not using anything that would prevent that. However I would assume that github codespaces doesn’t have the insiders version of our extension, so you would not see the fix there yet.