Host kernel not detected; all others OK

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 https://github.com/Anaconda-Platform/nb_conda_kernels/issues/112#issuecomment-437128926 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

[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.