Open joouha opened 1 year ago
This is also relevant:
When the ipykernel
wheel is built, the packaged kernelspec has just python
as the first argument of the kernel launch command.
If the user installs the kernel themselves (i.e. python -m ipykernel install --user
, the kernelspec is created with an absolute interpreter path.
You have to add envs manually like
{
"argv": [
"python",
"-m",
"ipykernel_launcher",
"-f",
"{connection_file}"
],
"env":{
"PATH": PATH after activate venv.
},
"display_name": "Python 3.10 (ddip)",
"language": "python",
"metadata": {
"debugger": true
}
}
Thanks for your reply, but I think you have misunderstood this issue I described:
I'm writing a new Jupyter client which I want users to run from a virtual environment (using pipx
). My client does not depend on ipykernel
.
Typically the user will have ipykernel
(and a corresponding kernelspec) installed in their system prefix.
When the user tries to launch a kernel from the system kernelspec it fails, because jupyter_client
incorrectly edits the kernelspec, substituting the python
argv command with the absolute path of the interpreter in the client's venv.
Since ipykernel
is not installed in the pipx
venv, launching the kernel fails.
I think in the case of a non-absolute python
command, cmd[0]
should be set to sys._base_executable
, unless the client is running in the same prefix that the connection_file
is located, in which case cmd[0]
could reasonably be set to sys.executable
.
I've received several reports from users where a Python kernel fails to launch when started by a Jupyter client running in a virtual environment (e.g. https://github.com/joouha/euporie/issues/25, https://github.com/joouha/euporie/issues/75), and I've tracked down the cause to these lines of code in
jupyter_client
.Let's say I have
ipykernel
installed in my system Python environment, and I want to run this kernel from a client (which usesjupyter_client
) installed in a virtual environment:jupyter_client
replaces thepython
command in the kernelspecargv
line with the path to the interpreter on whichjupyter_client
is running. This is implemented here:https://github.com/jupyter/jupyter_client/blob/ed7f9c27b0ae054e2b87d581f6252d240f2e6686/jupyter_client/manager.py#LL273C1-L284C36
I'm really not sure this is expected or desirable behaviour. There is a comment stating the following:
but I don't think this assumption is correct, and I don't understand what problem was this originally implemented to solve.