This is also relevant:

https://github.com/ipython/ipykernel/blob/f7e5a8fb5c37d81c55b9ea785168c8a19d110eb4/hatch_build.py#L23

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.