Current working directory for jupyter notebook sets to temp folder in vscode

Question:

I’m trying to set current working directory (CWD) to edited file location for Jupyter Notebook in VS Code. I use ${fileDirname} in python.dataScience.notebookFileRoot setting. However it uses temporary folder as ${fileDirname} instead of original file folder.

Same issue was discussed couple times already (e.g. https://stackoverflow.com/a/54794976/12488601) with tried solution pointed out.

Here is example of cwd:

os.getcwd()
.. 'C:\Users\MjH\AppData\Local\Temp\1f6cc207-562f-4ae1-8754-e2013ae2c12d'

While expected result is C:WorkspaceProject.

So use of ${fileDirname} does not work in my case. I use following ad-hoc solution, which, obviously, won’t update if file is moved.

import sys
import os
sys.path.insert(0, r'C:workspaceproject')
os.chdir(sys.path[0])

Now I’m trying to understand three things:

  1. is my case a unique one?
  2. if it’s general issue, is there a feature request/issue submitted for VS Code to address it?
  3. is there a better ad-hoc solution?

VS Code version: Code 1.40.2 (f359dd6, 2019-11-25T14:54:45.096Z)
OS version: Windows_NT x64 10.0.17763
Settings

Asked By: MjH

||

Answers:

To answer your third question, try this:

import os

os.system("echo %cd% > dir")
file = open("dir", "r")
filePath = file.read()
file.close()

print(filePath.split("n")[0])
Answered By: Anteino

I’m also affected by this issue.
Here is how I solved it.

Using the configuration parameter of ${fileDirName} in Python > DataScience: Notebook File Root, has this effect as I could check in my environment.

If I open an Python Interactive Window using the commands Ctrl+Shift+P > Python:Show Python Interactive Window, and then run:

import os
os.getcwd()

The output is a random temporal folder. So I couldn’t do imports cause my local relative modules where not found.

However, If instead of opening directly a fresh Python Interactive Window I run a cell of code of any of my python files

#%%
print("Some string here")

and then find the current working path, it changes to the fileDirName as expected. Then any interaction with the interactive window will perform correctly (and my next imports will perform correctly).

To avoid this behaviour and because I would like to perform operations within my workspaceFolder I changed Jupyter: Notebook File Root to ${workspaceFolder}. In this case opening a new fresh Python Interactive Window, will set the current path automatically to the workspaceFolder, with and without the need to execute any python cell.

I think that, when using ${fileDirName}, it would be good to set the current working open file folder as the working path of the Python Interactive Window (Jupyter) instead of the temporal random folder (In the case of opening without executing a specific cell), but doesn’t look like it behaves like that.

Hope it were useful!

Edit :

Since Nov 2020 the Jupyter extension is separated from Python
extension for VS Code. The setting key has been renamed from
python.data science to jupyter

Answered By: CristoJV

I had the same problem. I solved it by putting the setting into the settings.json file manually:

{
    "jupyter.notebookFileRoot": "${fileDirname}",
}

Why it solves the issue (my guess):

Jupyter changes the working directory when starting. After this, the notebookFileRoot settings from settings.json files are implemented, however as ${fileDirname} is default, this is not added to the json file. Therefore the file root will not be changed back to ${fileDirname} if the setting is set through the UI settings in vscode.

Answered By: Sebastian Pedersen

As of January 2021 adding the following line in my setting helps to solve the issue

"jupyter.notebookFileRoot": "${workspaceFolder}",
Answered By: Espoir Murhabazi

This is true solution to this problem.
Worked in my version of VS 1.76.2; JupyterEx v2023.2.1200692131

In user settings json file put this

{
"jupyter.runStartupCommands": [
        "import os",
        "__t=os.path.dirname(__vsc_ipynb_file__)",
        "%cd {__t}",
        "del __t"
    ],
}

It is using undocumented variable – so this might break in the future – but works for now.

Answered By: THOTH