Skip to content

Jupyter plugin hides some custom kernelspecs when the executable defined in the argv cannot be found #13796

Closed

Description

Environment data

  • VS Code version: 1.79.2
  • Jupyter Extension version (available under the Extensions sidebar): v2023.4.1001091014
  • Python Extension version (available under the Extensions sidebar): v2023.10.1
  • OS (Windows | Mac | Linux distro) and version: Linux Ubuntu 22.04 (same on CentOS7)
  • Python and/or Anaconda version: n/a
  • Type of virtual environment used (N/A | venv | virtualenv | conda | ...): n/a
  • Jupyter server running: Local (same container as vscode)

Expected behaviour

All kernel spec visible in JupyterLab interface should appear in VSCode/Jupyter Kernels list as well. Eventually explicit error message (or warning) is shown if kernelspec is incomplete or broken in some way.

Extend documentation in https://github.com/microsoft/vscode-jupyter/wiki/General-overview-of-Kernel-Discovery-&-Execution-in-Jupyter-(&-extension)#1-global-kernelspecs and/or https://code.visualstudio.com/docs/datascience/jupyter-kernel-management#_jupyter-kernels to explicitly state what paths are searched and how broken or incomplete kernelspec are handled.

I was giving up trying jupyter plugin after not being able to use my kernel with it until I realized why it skips my kernel spec.

Actual behaviour

Some kernels are silently skipped during detection.

Steps to reproduce:

Put a kernel spec into ~/.local/share/jupyter/kernels/custom/kernel.json with a command on system path:

{
    "display_name": "CUSTOM",
    "language": "python-custom",
    "argv": [
        "mycommand",
        "{connection_file}"
    ]
}

The kernel will be picked up by JupyterLab and will work as expected.
KernelPicker will not show the kernel in the list.

Resolution on my side was to change "mycommand" into "/full/path/mycommand" and it worked! Thanks for the great plugin!
EDIT: Per discussion below it's language set to be different from python (like "python-custom") that does the trick. With language set to "python", which is the default, the code makes some assumptions that are not valid for custom kernels.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

Labels

bugIssue identified by VS Code Team member as probable buginfo-neededIssue requires more information from posternotebook-kernel-pickerverifiedVerification succeeded

Type

No type

Projects

No projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions