kernelspec: interpret 'python' as sys.executable

[minrk]

allows kernelspecs to use 'python' as the executable to launch to indicate the parent environment, which in turn should enable Python packages providing kernelspecs to include their kernelspec in a wheel.

With activated environments, this makes no difference because which python and sys.executable are the same.

The only case where behavior should differ is when the Manager is in an env, but has been launched without activating the env, e.g. by absolute path (/path/to/env/bin/jupyter notebook). In this case, the new behavior seems preferable to the old.

This should only be used for portable kernelspecs (e.g. in wheels). Absolute paths are preferable wherever available (e.g. conda packages, local install from source).

cf ipython/ipykernel#223

[blink1073]

To be clear, the practical effect of this is that Python-based kernels (like wrapper kernels), can be distributed as wheels without requiring a separate install step?

[rgbkrk]

The way that Hydrogen gets around this (since it has to run from node) is to have a built in kernelspec where the command is python. Same thing will happen with nteract launching the system kernel since so many people expect it to "just work".

[minrk]

@blink1073 exactly right. The impediment to doing this right now is that kernelspecs embed absolute paths (not required, but a good idea), but pip doesn't allow rewriting sys.executable at install time on anything other than a script (pypa/pip#4032), unlike conda which handles it everywhere.

@rgbkrk that makes perfect sense. Any program other than Python itself should logically interpret python as the one on the PATH. I think there's a reasonable exception when the interpreter is already Python, in which case interpreting 'python' as itself, rather than checking the PATH again seems like a sensible thing to do.

[blink1073]

Sounds great!

[Carreau]

Sounds great!

Looks merged.

[blink1073]

cc @dsblank, w00t!