#!import using a path relative to the original notebook, rather than relative to the current working directory

[marckruzik]

Is your feature request related to a problem? Please describe. With #!import, I can import a notebook, even with a relative path.

#!import "../common/library/repo.dib"

Usually, the current working directory (Directory.GetCurrentDirectory()) corresponds to the directory which contains the notebook. But when I import a notebook containing a relative reference to another notebook, due to the current working directory being different, the relative path no longer works (see example).

I wrote down an example:

• folder1/A.dib

  • !import ../B.dib

• folder2/B.dib

  • !import C.dib

• folder2/C.dib

In this example, I can run B, and it imports C. But if I run A, it imports B, and fails to import C.

In this kind of situation, Jupyter Notebook users usually change the current working directory to the folder of the file. It looks like the following:

• folder1/A.dib

  • !import ../B.dib

• folder2/B.dib
  • cd folder2

  • !import C.dib

• folder2/C.dib

It's not good, as it changes the current working directory, affecting the process.

Describe the solution you'd like I would like a parameter to specify that the path is relative to the directory of the notebook which contains the cell.

#!import --relativeToThisNotebookDirectory ../C.dib

Or I would like some kind of variable to express the path of the notebook file path or its directory.

#!import __this_notebook_directory__/../C.dib

Jupyter Notebooks have a variable file, which contains the file path of the actual notebook (the availability of file depends on the implementation of the platform). We also could have a directory variable, which contains the directory path of the actual notebook.

Any working solution is important to me, as I have often the need to chain several notebooks together.

Describe alternatives you've considered

• Using absolute paths to load secondary notebooks
• Changing current working directory

[anatoliy-savchak]

Looking forward for this feature!

[NikiforovAll]

I also encounter this behavior. I consider this as a bug, to be honest.