Jupyter notebook written using VSCode makes build crash with NoSuchKernel error

[ksachdeva]

A notebook authored using VSCode built-in editor fails to build.

Steps to reproduce the behavior:

• Use VSCode built-in editor/support to write your Jupyter Notebook
• Make sure to execute at least one cell in VSCode
• Issue jupyter-book build .

This results in build failing with an exception/error - "NoSuchKernel ..." Here is a trace of the error stack

Environment

• Python Version 3.7.8 in virtualenv
• Package versions : jupyter-book 0.8.2
• Operating System: macOS
• IDE: VSCode

Workaround

Here is how I work around this issue-

Open the notebook in raw mode (i.e. json file) and remove kernelspec section. For e.g.

I go to the location where I have below shown json blob

"orig_nbformat": 2,
  "kernelspec": {
   "name": "Python 3.7.8 64-bit ('prmlenv': venv)",
   "display_name": "Python 3.7.8 64-bit ('prmlenv': venv)",
   "metadata": {
    "interpreter": {
     "hash": "ec5a04176abb2f15087dd010db8344c4d46cfabf8263c1804b67e1f772428e7e"
    }
   }
  }

I then delete the whole kernelspec

This makes jupyter-book build happy.

Needless to say, it adds/introduces an extra step for me per notebook.

I am not sure if it is VSCode at fault here or jupyter-book is not able to find the appropriate kernel. Note that both use the same virtualenv.

Regards
Kapil

[welcome]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉

[chrisjsewell]

Eurhh, I'm going to tag this as discuss, rather than a bug for now.
Because its a known thing, but I'd say more of a bug/question for VS Code to answer:
VS Code sets "special" kernelspec based on the python interpreter you have selected.
The problem with this is that they only work locally within your VS Code application. For example, if you try to open it in Jupyter Lab, you will get this dialog, asking you to set a new kernel, because it does not recognise the one that VS Code sets:

by contrast, if you create a new notebook in jupyter lab, it will just create a generic kernel spec, which is recognised by any interpreter running python3:

  "kernelspec": {
   "display_name": "Python 3",
   "language": "python",
   "name": "python3"
  },

If possible I would ask if you (or anyone else interested) could ask VS Code about this and if there is a way to just set a generic kernel name.

[ksachdeva]

Understood; I did suspect that it is something bizarre that VSCode is doing. I will ask in their forum.

Thanks for the very quick responses; much appreciated this whole effort.

[tnwei]

Was halfway through typing up a new issue (same issue w/ jupyterlab) until I found this. I'm not sure what role the kernel spec metadata plays in the build process, wonder would it be beneficial to implement the fix described in this issue? I personally would be happy to know that regardless how the different versions of Python are being managed on my system, jb's build would work. Interested to hear more opinions about this.

More context: The nb_conda_kernels package for jupyterlab does the same thing as VS Code when it comes to modifying env names, which allows running jupyterlab on one conda environment while enabling it to access other conda environments that have ipykernel installed. This causes the base environment to look like this instead:

"kernelspec": {
   "display_name": "Python [conda env:root] *",
   "language": "python",
   "name": "conda-root-py"
  }

Saving the notebook while using a condaenvironment named qe-mini-example (it's the example from the docs) would look like this:

"kernelspec": {
   "display_name": "Python [conda env:qe-mini-example]",
   "language": "python",
   "name": "conda-env-qe-mini-example-py"
  }

[chrisjsewell]

wonder would it be beneficial to implement the fix described in this issue

Sorry, I'm not sure I understand what fix you are referring to?

IMO I think its a bad idea to be "tying" your notebook to a specific local kernel, if you want to share it,
unless there is an automated way to re-generate this kernel on any system?

[tnwei]

Sorry, I'm not sure I understand what fix you are referring to?

Ah should have been more explicit, in the first post ksachdeva is able to get jb build to run by removing the kernel spec metadata.

IMO I think its a bad idea to be "tying" your notebook to a specific local kernel, if you want to share it,
unless there is an automated way to re-generate this kernel on any system?

I concur, thus thinking if it is possible to ignore the kernel spec metadata instead of having it throw errors.

[welcome]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉