Jupyter Server Fails to launch

[meatballs]

Environment data

• VS Code version: 1.29.1
• Extension version: 2018.11.0
• OS and version: macOS 10.14.1 (Mojave)
• Python version: Anaconda 3.7.0
• Type of virtual environment used: conda

Actual behavior

When settings.json exists within .vscode and includes a python.pythonPath entry pointing to a conda virtual environment, the jupyter server fails to launch.

If the .vscode folder is deleted, vscode restarted and the same interpreter selected from the menu, the jupyter server starts ok.

Expected behavior

Jupyter server starts and cells execute both when the interpreter is first selected and also when the editor is restarted in the same project.

Steps to reproduce:

1. Create the following python file in a new folder:

# %%
print("hello")

1. Execute the cell
2. Select a conda virtual environment as the interpreter and wait for the kernel to restart
3. Execute the cell (which should succeed)
4. Restart vscode in the same folder
5. Execute the cell - the server fails to start

Logs

Output for Python in the Output panel (View→Output, change the drop-down the upper-right of the Output panel to Python)

None

Output from Console under the Developer Tools panel (toggle Developer Tools on under Help)

Jupyter notebook failed to launch.  Error: The Jupyter notebook server failed to launch in time
  | t.onDidNotificationChange | @ | /Applications/Visual…kbench.main.js:2429
  | (anonymous) | @ | /Applications/Visual…kbench.main.js:2429
  | e.fire | @ | /Applications/Visual…rkbench.main.js:183
  | t.notify | @ | /Applications/Visual…kbench.main.js:2484
  | t.notify | @ | /Applications/Visual…kbench.main.js:3530
  | e._showMessage | @ | /Applications/Visual…kbench.main.js:3242
  | e._showMessage | @ | /Applications/Visual…kbench.main.js:3241
  | e.$showMessage | @ | /Applications/Visual…kbench.main.js:3241
  | t._doInvokeHandler | @ | /Applications/Visual…kbench.main.js:3278
  | t._invokeHandler | @ | /Applications/Visual…kbench.main.js:3278
  | t._receiveRequest | @ | /Applications/Visual…kbench.main.js:3277
  | t._receiveOneMessage | @ | /Applications/Visual…kbench.main.js:3276
  | (anonymous) | @ | /Applications/Visual…kbench.main.js:3273
  | e.fire | @ | /Applications/Visual…rkbench.main.js:183
  | a | @ | /Applications/Visual…rkbench.main.js:337
  | n._socketDataListener | @ | /Applications/Visual…rkbench.main.js:338
  | emitOne | @ | events.js:116
  | emit | @ | events.js:211
  | addChunk | @ | _stream_readable.js:263
  | readableAddChunk | @ | _stream_readable.js:250
  | Readable.push | @ | _stream_readable.js:208
  | onread | @ | net.js:594

[rchiodo]

Can you try two things?

First, if you increase the timeout, does that give jupyter enough time to start?

Second, can you include all of your console output here? What does the console show before the timeout?

[meatballs]

Increasing the timeout made no difference - in fact, if I watch the processes on my machine, I can see a jupyter process start and then terminate almost immediately.

[meatballs]

Aha! I think we may have it...

[Extension Host] Python Extension: [C 19:01:54.447 NotebookApp] Bad config encountered during initialization:
[C 19:01:54.447 NotebookApp] The 'contents_manager_class' trait of <notebook.notebookapp.NotebookApp object at 0x10d8f36d8> instance must be a type, but 'jupytext.TextFileContentsManager' could not be imported

appears in the developer console as the server attempts to start.

[rchiodo]

Could you try the insiders build? We added some more support for finding the conda activation script. This might be causing jupyter to fail to start. Although I would have expected some output from it.

Also do you happen to have a global jupyter config setup? That might also change the behavior.

[meatballs]

I've tried the insiders build and had the same behaviour. I've just removed the jupytext line from my global jupyter config and the problem has gone away.

[meatballs]

So, I suspect this is something to do with me not having jupytext installed in either the base conda or the virtual env (not sure which at the moment).

It's odd that it all behaves perfectly when the virtual env is first selected as the interpreter but not if the .vscode setting already exists - but my problem is fixed, so I'm happy!!

Thanks for the pointer @rchiodo

[rchiodo]

This should be fixed now that we generate our own config to use with jupyter.
See this PR microsoft/vscode-python#3558
You can try it out in our insiders build