Did the kernel starting mechanism change in a recent pre-release? #13106
Replies: 3 comments
-
@leifwalsh please can you file a bug for this issue and to answer your question yes, yes we did change a few things Please could you enable logging as follows:
|
Beta Was this translation helpful? Give feedback.
-
@leifwalsh please do create an issue when possible |
Beta Was this translation helpful? Give feedback.
-
Thanks. Did my best here: #13107 Let's continue there and if you have other questions I can try to answer them. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I run the pre-release version of this extension to try to stay ahead of regressions, and I think I noticed one in our environment. I think this might be related to the "streamlining" mentioned in #12999.
Is it the case that, in the non-remote jupyter server mode, the extension now runs
jupyter notebook
to start a local notebook and then connects to that to start kernels? Is it the case that it used to directly run the kernel and interact with it as if the extension were the jupyter server?If so, I think something we've done in our environment makes jupyter in vscode break with this change and I need to figure out what we can do about it before this change hits normal releases.
The thing we've done is that we have a customized version of jupyter internally, and to avoid confusion the team that owns it changed the
jupyter
andjupyter-notebook
commands to print an error (instructing the user to use the custom command name) and exit. I think this makes everything break with the pre-release version of vscode-jupyter.I realize this is a very https://xkcd.com/1172/ style "bug", so I'm starting this as a discussion just to find out if that is what happened first.
Beta Was this translation helpful? Give feedback.
All reactions