Host kernel not detected; all others OK

[ralexx]

When launching jupyter notebook from a conda env running Python 3.7 and nb_conda_kernels 2.2.0, the notebook fails to identify the kernel of host environment from which Jupyter was launched. [edit: this behavior also found using Python 3.6 build in 3.6 env].

Using conda-forge::nb_conda_kernels=2.1.1=py36_1001 in a Python 3.6 env gives expected behavior: all kernels are available.

Similar problem to #112 (comment) but I think this is different from #112.

Example 0

$ conda activate py37
$ jupyter notebook

Jupyter file browser opens; click on New

• All Python 3.6 kernels available
• R kernel available
• My other Python 3.7 kernel (s37) available but not the host py37

Example 1

Equivalent result when I activate a different Python 3.7 env and launch jupyter notebook:

$ conda activate s37
$ jupyter notebook

The py37 env from the previous example is visible and operable.

Versions (both 3.7 envs)

nb_conda_kernels          2.2.0                 py37_1000    conda-forge
jupyter                   1.0.0                      py_1    conda-forge
jupyter_client            5.2.3                      py_1    conda-forge
jupyter_console           6.0.0                      py_0    conda-forge
jupyter_core              4.4.0                      py_0    conda-forge 
python                    3.7.0                h4eca856_1    conda-forge

conda info --all

conda info --all                                                   14:49:02

     active environment : None
            shell level : 0
       user config file : /Users/ralexx/.condarc
 populated config files : /Users/ralexx/.condarc
          conda version : 4.5.11
    conda-build version : 3.16.2
         python version : 3.7.1.final.0
       base environment : /usr/local/share/anaconda  (writable)
           channel URLs : https://conda.anaconda.org/ralexx/osx-64
                          https://conda.anaconda.org/ralexx/noarch
                          https://conda.anaconda.org/conda-forge/osx-64
                          https://conda.anaconda.org/conda-forge/noarch
                          https://conda.anaconda.org/intel/osx-64
                          https://conda.anaconda.org/intel/noarch
                          https://repo.anaconda.com/pkgs/main/osx-64
                          https://repo.anaconda.com/pkgs/main/noarch
                          https://repo.anaconda.com/pkgs/free/osx-64
                          https://repo.anaconda.com/pkgs/free/noarch
                          https://repo.anaconda.com/pkgs/r/osx-64
                          https://repo.anaconda.com/pkgs/r/noarch
                          https://repo.anaconda.com/pkgs/pro/osx-64
                          https://repo.anaconda.com/pkgs/pro/noarch
          package cache : /usr/local/share/anaconda/pkgs
                          /Users/ralexx/.conda/pkgs
       envs directories : /usr/local/share/anaconda/envs
                          /Users/ralexx/.conda/envs
               platform : osx-64
             user-agent : conda/4.5.11 requests/2.19.1 CPython/3.7.1 Darwin/16.7.0 OSX/10.12.6
                UID:GID : 501:20
             netrc file : None
           offline mode : False

[michaelaye]

Same/similar here.
I have this on offer in the notebook:

while my conda env list says this:

$ conda env list                                                                                  (py37)
# conda environments:
#
base                     /Users/klay6683/miniconda3
isis3                    /Users/klay6683/miniconda3/envs/isis3
py2                      /Users/klay6683/miniconda3/envs/py2
py36                     /Users/klay6683/miniconda3/envs/py36
py37                  *  /Users/klay6683/miniconda3/envs/py37
vpython                  /Users/klay6683/miniconda3/envs/vpython

I don't understand why VPython appears twice? And my py37 host is missing as well.
What about the base environment? Is it automatically omitted?
The server says 4 kernels found in the beginning:

$ jupyter notebook .                                                                              (py37)
[I 12:59:53.354 NotebookApp] [nb_conda_kernels] enabled, 4 kernels found

The lack of isis3 offering is okay, because that's not a Python env and it doesn't have notebook kernels either.

[michaelaye]

I just noticed that the first entry in the kernel menu called "Python 3" is ACTUALLY my conda py37 environment, at least that's what a which ipython tells me?

[mcg1969]

That's right. Python 3 the kernel you want in this case. It's the kernel in the environment you launched Jupyter from.

[mcg1969]

So this raises an interesting UX question. The kernel in the "host" environment is there; it just doesn't follow the naming convention the other kernels are given. The only kernels in the conda env list are the ones that had to be located by looking at other conda environments. So, for instance, if you happened to have kernels listed in the "global" kernel spec directory (/usr/local/share/jupyter/kernels, I believe?) those would show up as well, without conda env in the name.

Putting the "host" environment back would eliminate the confusion, at the expensive of redundancy--the host kernel would appear twice in the list, under different names. I'm open to that, especially if someone else makes the PR :-) but I wonder if it ought to be optional.

[ralexx]

@mcg1969 , In nb_conda_kernels 2.1.x, as long as the user had selected a named kernel to run a notebook they could reopen that notebook with the correct kernel irrespective of host env.

Under nb_conda_kernels 2.2.0, I either have to remember which host env I ran a particular notebook from -- since they will all claim to be Python 3 in my case -- or else I have to use a dedicated notebook "runner" env. This is where I first got bitten with the new version: I opened a notebook from a different host env and experienced import errors from dependencies.

It looks like you changed the behavior in 25dcca8. Would it be acceptable to revert to the previous behavior of including the host env in the dict of environments? I haven't dug into the code far enough to understand how environments are excluded: if a UI mod is needed that's probably over my head.

[mcg1969]

Indeed, I think y'all are right—the duplication in the kernel list is better than the confusion. We can even, say, put some sort of indicator into the format noting the current environment. I'm open to a PR on this, and at some point I'll take a look.

[marabout2015]

I would have been a big time saver to include this change of behavior in the list of breaking changes. I know multiple people beside myself who have been scratching their heads over this bug. The sooner you can push the new version the better.