AttributeError: 'IOLoopKernelManager' object has no attribute 'extra_env'

[web-sys1]

I've encountered a kernel error while prompting from Jupyter command: 'IOLoopKernelManager' object has no attribute 'extra_env'. I typed --KernelManager.kernel_cmd through ipython..jupyter via command prompt to see how it works, and I got an error:

Traceback (most recent call last):
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\tornado\web.py", line 1703, in _execute
    result = await result
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\tornado\gen.py", line 742, in run
    yielded = self.gen.throw(*exc_info)  # type: ignore
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\notebook\services\sessions\handlers.py", line 69, in post
    model = yield maybe_future(
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\tornado\gen.py", line 735, in run
    value = future.result()
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\tornado\gen.py", line 742, in run
    yielded = self.gen.throw(*exc_info)  # type: ignore
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\notebook\services\sessions\sessionmanager.py", line 88, in create_session
    kernel_id = yield self.start_kernel_for_session(session_id, path, name, type, kernel_name)
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\tornado\gen.py", line 735, in run
    value = future.result()
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\tornado\gen.py", line 742, in run
    yielded = self.gen.throw(*exc_info)  # type: ignore
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\notebook\services\sessions\sessionmanager.py", line 100, in start_kernel_for_session
    kernel_id = yield maybe_future(
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\tornado\gen.py", line 735, in run
    value = future.result()
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\notebook\services\kernels\kernelmanager.py", line 176, in start_kernel
    kernel_id = await maybe_future(self.pinned_superclass.start_kernel(self, **kwargs))
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\jupyter_client\multikernelmanager.py", line 185, in start_kernel
    km.start_kernel(**kwargs)
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\jupyter_client\manager.py", line 309, in start_kernel
    kernel_cmd, kw = self.pre_start_kernel(**kw)
  File "c:\users\hp 9\appdata\local\programs\python\python38\lib\site-packages\jupyter_client\manager.py", line 271, in pre_start_kernel
    elif self.extra_env:
AttributeError: 'IOLoopKernelManager' object has no attribute 'extra_env'

When I came to the webpage to read the Configuration options page then then I caught:

KernelManager.kernel_cmd : List

DEPRECATED: Use kernel_name instead.

The Popen Command to launch the kernel. Override this if you have a custom kernel. If kernel_cmd is specified in a configuration file, Jupyter does not pass any arguments to the kernel, because it cannot make any assumptions about the arguments that the kernel understands. In particular, this means that the kernel does not receive the option –debug if it given on the Jupyter command line.

I'm wondered the command is deprecated. Can anyone help to deal with this issue?

[kevin-bates]

Interesting. I think you've stumbled upon a "hidden gem" of an issue - the manual configuration of KernelManager.kernel_cmd doesn't work. 😄

Given this was deprecated more than 7 years ago, I think we could take a couple of approaches.

1. Go ahead and remove this deprecated feature, once and for all.
2. Properly define extra_env.

It's item 2 that has me puzzled. If I use git blame on the elif self.extra_env: statement, it rightly shows my commit for the templated envs PR. Yet, I know I didn't just add the elif and, looking at the PR itself, and the changes that it includes, you see there was an elif there already that my PR only amended. I'm sure this SNAFU had something to do with some branch manipulations where (I think) master became kernel_discovery and master was rebuilt from 5.x or something like that. At any rate, I think the elif statement could be removed in its entirety - leading to option 3...

3. Remove the elif: self.extra_env block.

Since I feel somewhat responsible for this mess, I'm happy to correct it, but would like to discuss which of these approaches (or any others) we should take. Frankly, given kernel_cmd has been listed as deprecated for 7+ years, I think its time to remove it. My understanding is that this kind of action typically requires a major release, but given its history and the fact that we know no one is using it, at least in the 6.x timeframe, I suspect its safe to perhaps carry the change in a minor release.

I also believe we should go ahead and take option 3 regardless. I don't actually view Option 2 as an option. Its really, at this point, just rogue code.

I'm going to go ahead and submit a PR to take Option 3. Since that effort is a subset of Option 1, we can amend the PR to include Option 1 based on what we decide.

@web-sys1 - thank you for bringing this to our attention. For the time being, you should avoid configuring the deprecated kernel_cmd option.

[kevin-bates]

I'm thinking now (after submitting the #581) it might be best to take this in two steps. Remove extra_env, then plan kernel_cmd's removal.

[web-sys1]

@kevin-bates then, what type of commands can be useful? I miss the kernel_cmd.

[kevin-bates]

I see. I thought you were just experimenting with kernel_cmd, but you actually use it?
Did you just update your juptyer_client to > 6.x?

My guess is that it was deprecated because folks could simply configure the command they want in the argv stanza of the named kernelspec. Have you explored doing that?

This is good information - thank you. Given a 7-year deprecation phase, I think we need to apply some action and follow through with its removal or retract the deprecation and support it forever. It doesn't play well with multi-kernel support which I believe is why this was deprecated in the first place.

At any rate, you should be able to use kernel_cmd again by building from my branch, waiting for the next patch release, or install the dev-build I've posted here (you'll need to remove the .zip suffix, then pip install the wheel).

jupyter_client-6.1.7.dev0-py3-none-any.whl.zip

[web-sys1]

I see. I thought you were just experimenting with kernel_cmd, but you actually use it?
Did you just update your juptyer_client to > 6.x?

My guess is that it was deprecated because folks could simply configure the command they want in the argv stanza of the named kernelspec. Have you explored doing that?

This is good information - thank you. Given a 7-year deprecation phase, I think we need to apply some action and follow through with its removal or retract the deprecation and support it forever. It doesn't play well with multi-kernel support which I believe is why this was deprecated in the first place.

Sure. Ipykernel does and kernels are supplied through host to notebook. The path ./Python/Python38/share/jupyter/kernels/python3/kernel.json takes over the location of the JSON file.

{
 "argv": [
   "python",
  "-m",
  "ipykernel_launcher",
  "-f",
  "{connection_file}"
 ],
 "display_name": "Python 3",
 "language": "python"
}

[kevin-bates]

Sure. Ipykernel does and kernels are supplied through host to notebook. The path ./Python/Python38/share/jupyter/kernels/python3/kernel.json takes over the location of the JSON file.

If you're saying that installation of the ipykernel overwrites your customization, create your kernel.json in a sibling directory and reflect that change in the display_name so as to decipher between the two via the UI.