You can configure several aspects of the plugin such as the Python executable to start Jupyter or whether or not to display a ribbon icon.

A rundown of all the settings is available here.

Available Settings

Python

Python executable to use

Whether to use the simple python command to start Jupyter, or a particular Python executable file.

If set to Specified executable path, the Python executable path setting will be used.

Set to python by default.

Python executable path

The Python executable path to use to start Jupyter. This setting has no effect if Python executable to use is set to python.

Empty by default.

Jupyter

Server running

Not a setting properly speaking, this toggle indicates the state of the server. If the server is starting or running, the toggle is on. If the server has exited or has not been started, the toggle is off.

Start Jupyter automatically

Whether to automatically start the Jupyter server when a .ipynb file is opened if Jupyter is not running.

Default value is yes.

Jupyter environment type

Whether to use Jupyter Lab or Jupyter Notebook.

Note that if the Jupyter server is running while you change this setting, you will need to stop it and start it again for the new value to take effect.

Default value is Jupyter Lab.

Simple Interface

Jupyter Lab provides an appearance setting called Simple Interface. It hides unnecessary UI elements for the user to concentrate on the file that is being edited. No Jupyter tabs, no sidebars, just the file.

This setting defines whether notebooks should be opened in Simple Interface mode by default.

Has no effect if the environment type is Jupyter Notebook.

Default value is enabled (meaning all notebooks will be opened in Simple Interface mode).

Delete Jupyter checkpoints

When working with notebooks, Jupyter generates checkpoint files. This creates a new .ipynb_checkpoints directory in each directory where you have a notebook opened. It becomes messy very fast.

This setting helps you keeping your vault clean. If enabled, checkpoints will be deleted automatically.

The deletion does not work retroactively though, meaning that if checkpoints were created before you enable the feature, they won’t be deleted. The setting only applies to future checkpoints.

Note that if the Jupyter server is running while you change this setting, you will need to stop it and start it again for the new value to take effect.

This setting is disabled by default.

Move Jupyter checkpoints to trash

If enabled, Jupyter checkpoints will be moved to the system trash instead of being permanently deleted. This can be useful if you want to still make sure you can always restore checkpoints.

This setting has no effect if Delete Jupyter checkpoints is disabled.

By default, Jupyter checkpoints are moved to trash (enabled).

Note that if checkpoints are stored outside of the vault folder (see Jupyter checkpoints folder setting), moving them to trash won’t work and will display an error notice without deleting or moving the checkpoints. In this case, this setting can be disabled to delete the checkpoints permanently, which will still work.

Jupyter checkpoints folder

Defines where to store the checkpoints generated by Jupyter. Has no effect if Delete Jupyter checkpoints is not enabled.

  • By default, the checkpoints are not deleted and stored in the same folder as the corresponding .ipynb file.
  • If deletion is enabled, but this setting is empty, checkpoints are stored in a default location, inside of the plugin’s Obsidian directory, and deleted when Jupyter exits.
  • If deletion is enabled and this setting is set to a path, a .ipynb_checkpoints directory will be created as a sub-folder of the indicated folder, and all checkpoints will be stored inside of it. This can be useful if you do not want checkpoints to be inside of your vault’s directory, to avoid syncing them for example.

Note that if the Jupyter server is running while you change this setting, you will need to stop it and start it again for the new value to take effect.

By default, this setting is blank (no path set, see the list above for what this implies).

Relative paths are accepted and will be resolved relative to the Jupyter’s root folder (meaning the root folder of the vault).

This setting allows to store the checkpoints outside of the vault using an absolute path. This is particularly useful if some automatic backup system is set up on the vault, and the user does not want to backup the Jupyter checkpoints. In this case, checkpoints can be stored outside of the vault in a user-defined location. However, note that if checkpoints are stored outside the vault, trashing no longer works. This means that if checkpoints are outside the vault, having the Move Jupyter checkpoints to trash setting enabled will display an error notice and won’t delete the checkpoints. Deleting the checkpoints permanently still works.

Plugin customization

Update popup

When the plugin gets an update, a popup will show to tell the user that a new version of Jupyter for Obsidian was installed with links to the GitHub releases and a list of the changes that were performed.

This popup is enabled by default but can be disabled using this setting.

Ribbon icon for server status

Jupyter for Obsidian can display a ribbon icon that adapts based on the Jupyter server status (running, exited or starting). This setting defines whether that ribbon icon should be drawn.

The setting is thought for users who have many plugins installed who do not want to crowd their ribbon icons bar too much.

Default value is yes (the ribbon icon is displayed).

Display status notices

Whether to display status notices when the Jupyter server state updates. A notice will appear every time the server is started, running, or exits.

Default value is yes (the status notices are displayed).

Ribbon icon for new notebooks

Defines whether another ribbon icon (different from the one for server status) is drawn. This second ribbon icon allows the user to create a new Jupyter notebook file at the root of the vault.

This ribbon icon is independent from the server status one, meaning that it can be enabled whether the ribbon icon for server status is enabled or not, and vice-versa.

Default value is yes (the ribbon icon is displayed).

Folder context menu for new notebooks

When right-clicking on a file or folder, Obsidian will offer some actions to the user that can be performed on this item. This setting defines whether Jupyter for Obsidian should add its own custom action to the list and offer the user to create a new Jupyter notebook when the user right-clicks on a folder.

Default value is yes (the Jupyter context menu item will be available).

Open created notebooks

Defines whether to immediately open new notebook files when they are created, and how to open them (in a new tab, in a detached window).

Possible values are

  • Do not open, simply create the file without opening it
  • Open in the current tab, like the general behavior in Obsidian, replace the currently active document (if any) with the newly created notebook
  • Open in a new tab, create the file and then open it in a new tab, without replacing the active file
  • Open in a new split tab, create the file, split the current workspace and open the new notebook in the new split tab
  • Open in a detached window, create the file and open it in a detached window

By default, new notebooks are opened in a new tab.

Advanced

Jupyter starting timeout

Number of seconds to wait before Jupyter is considered to time out in the starting state. If Jupyter takes too long to get ready, it will be shutdown and an error will be displayed.

This setting is to avoid Jupyter staying in the starting state for too long. Please note that making this setting too low might prevent Jupyter to even have the time to start at all.

Default value is 30 seconds.

Whether to print what Jupyter prints to the Obsidian console.

When Jupyter is started from a terminal, it prints many setup and log messages, which can be interesting for debugging, understanding a problem, or get the Jupyter URL and token to access it in a browser. This setting allows you to print all of those messages to the Obsidian console.

Default value is no (nothing will be printed).