Kernel manager that detects virtual/conda env & installs ipykernel

[takluyver]

This may be a separate package rather than something that belongs in jupyter_client, but this seems like the logical place to record the idea.

A custom kernel manager could detect when a frontend has been started with a (virtual|conda) env active, by looking at environment variables, invoke pip/conda to ensure ipykernel is installed in the env, and then launch a kernel using it. This would be especially useful for the console interfaces, similar to the virtualenv detection we do in IPython terminal.

This would make a good project that someone technically savvy but unfamiliar with our architecture could put together in ~a day, with some support from a mentor who knows our architecture.

Follows on from discussion on ipython/ipykernel#96

[minrk]

I'm pretty sure someone already made this. I haven't been able to find it with a quick googling.

[jankatins]

This is basically https://github.com/Cadair/jupyter_environment_kernels and especially Cadair/jupyter_environment_kernels#6 which implements conda envs and makes it work on windows. This currently checks for ipython in an env and and if ipython{.exe} is there, a kernel entry is generated on the fly.

The biggest problem I haven't found a solution for is how to activate the env: it's no problem to start a kernel in such an env, simple by specifying the full path to the python in that env, but it breaks if there is an app in the env, which the a kernel process expects but which is not in PATH because the env wasn't activated. -> #127 (Use case: installing pandoc/latex in an env...)

[takluyver]

I think this is a bit different: my suggestion here was to detect if there is an environment already active, and install ipykernel in that if so. With IPython 4.x, if you have a virtualenv active when you run the notebook server, it will kind of respect that by adding the virtualenv site-packages to sys.path.

But a) that's not the same as properly running in an isolated env, b) it's specific to virtualenv, not conda, and c) we're getting rid of that as a kernel feature with ipykernel 5.0. So I wrote this proposal as a suggestion for people who like that feature in ipykernel 4.x, as a better way to achieve the same thing.