microsoft
Running a Python script generated from a notebook (ipynb) file doesn't use the same kernel of the original notebook.
Applies To
- [ ] Notebooks (.ipynb files)
- [X] Interactive Window and/or Cell Scripts (.py files with #%% markers)
What happened?
Repro
- Open a Python file in VS Code and use the
Python: Select Interpreterto select any interpreter. Ex. "Python 3.7.10 64-bit ('base': conda)" - With a notebook that was last run using any kernel other than the selected Python interpreter (Ex. "Jupyter Kernel A"), convert it to a Python file by right clicking on the file in the VS Code Explorer and choose
Convert a Notebook to Python Script. (Could also be done in a notebook viaJupyter: Export to Python Script) - Run the script via the
Run Belowcode-lens on the first cell.
Result
It's unlikely the notebook will run all the way through since the Interactive Window is started using the selected Python interpreter, not the kernel of the original notebook.
Expected
The converted script should run all the way through.
Suggested resolution:
On conversion of the script, add a special cell to the top of the script that specifies the kernel of the originating notebook. Something like:
# %% [origin kernel]
# Jupyter Kernel A
When starting the interactive window, attempt to use the specified kernel before falling back to the selected interpreter.
VS Code Version
Version: 1.62.0-insider (user setup) Commit: ff1e16eebb93af79fd6d7af1356c4003a120c563 Date: 2021-10-29T05:16:23.014Z Electron: 13.5.1 Chrome: 91.0.4472.164 Node.js: 14.16.0 V8: 9.1.269.39-electron.0 OS: Windows_NT x64 10.0.22489
Jupyter Extension Version
v2021.10.1001398262
Jupyter logs
No response
Coding Language and Runtime Version
No response
Language Extension Version (if applicable)
No response
Anaconda Version (if applicable)
No response
Running Jupyter locally or remotely?
No response
%% [origin kernel]
This is basically what Jupytext with MYST does, all metadata is stored in python file. This is similar to the shebang in unix.
Problems:
- The shebang is not supported/not honoured in Python extension (this would be inconsistent in Jupyter extension if we started using this)
- Suggestion, add a code lens that allows user to set active interptreter to the interpreter defined in the first line
# %% [origin kernel]
- Suggestion, add a code lens that allows user to set active interptreter to the interpreter defined in the first line
- When using regular debugger, regular run file in terminal and the like, the python extension will use the current interpreter and not this one.
- Inconsistency: if this file is shared with someone else and they don't know about this, now the file is using a completely different kernel & they might not know what it is and why they cannot change it. Eg. we could end up breaking a lot of users using using python files if this magically appears.
Not sure how this is nb-golden? This has never worked and nobody has every asked for it.
It's not nb-golden. It's iw-golden. My thought here was that it seems inconsistent that after converting a notebook you may have just turned into a script, when you run the script, it probably won't be using the kernel notebook was run in. So the user is forced to select and restart the kernel. This feels like an iw-golden path issue (not blocking issue, mind you) as it affects what feels like an obvious workflow problem.
- Run a notebook successfully
- Convert it to a Python script using a built in conversion tool that will target another built in feature.
- Run the resulting Python script. FAIL.
As for Don's comments, yeah that all makes sense. However, if the kernel information is placed in a comment, we could obviously also provide an explanatory comment. Users are free to ignore it or remove it if they don't know what it is.
An alternative/additional idea might be to simply have a notification or dialog box at the end of the conversion asking if the user would like to change the selected Python environment to match the converted notebook's (if it doesn't match). Not sure this would be adequate/possible though if the user ran the notebook using a Jupyter Kernel (kernelspec.json).
Closing this issue as there haven't been any upvotes on this and users haven't complained about this. Also the new kernel picker will ensure users always select a kernel