Proposal: drop explicit call to ipykernel install

[SylvainCorlay]

At the moment, the recipe for ipykernel includes an explicit call to ipykernel install

    - {{ PYTHON }} -m ipykernel install --prefix {{ PREFIX }}

which in turns calls the jupyter-kernel entry point from jupyter_client. We have seen this cause some issues with permissions on windows, namely [Errno 13] Permission denied: 'C:\\xeus-conda\\Scripts\\jupyter-kernel.exe'.

In fact, we should not need to do this at all since a kernel spec can be included as part of the python package. The only issue with the current way the default kernelspec file generated by setup.py is made with make_ipkernel_cmd(executable='python') so that the kernel spec argv simply specifies "python" instead of the full sys.executable.

One way to fix this, would be for setup.py to check if some environment variable is set (e.g. IPYKERNEL_PYTHON) pass it to the executable kwargs.

Then the install command would merely be:

{{ PYTHON }} -m pip install . --no-deps --ignore-installed

[SylvainCorlay]

cc @takluyver @minrk.

[bollwyvl]

Thanks for the sleuthing! Simpler is better! If the required change is just removing the line in the feedstock, and all the tests still pass, we should just do it, barring any other reservations from the above... #43 dug up some other interesting tidbits, so would be a good starting point, unless this change obviates the need for the explicit wheel building.

[bollwyvl]

After going around a bit on this some more (#51):

• the kernel.json is what is keeping this feedstock from being noarch
• losing the full env path would be detrimental, as I don't think the machinery is in place to cope with it, yet (Draft proposal for new kernel providers mechanism and associated changes jupyter/enhancement-proposals#45, [DRAFT] Parameterized Kernel Launch jupyter/enhancement-proposals#46)
• even with the full path, it's still annoying that it doesn't do a "real" activation, and conda run still doesn't work reliably (Adding proper activation for conda envs to ipykernel creation ipython/ipykernel#417)

I guess we keep this open!

[SylvainCorlay]

Hey @bollwyvl I missed your comment on this issue.

I totally agree with you that we should not drop the full path. It would indeed be terrible to do so - and would prevent registering kernels from other environments.

I had some hope that we could get the full path when installing from a source tarball but it is impossible with recent versions of pip as per this issue, because pip now always builds an intermediary wheel when installing from a source tarball, even when explicitely requiring not to do so.

Now, I don't think we will be able to resolve this issue and drop the explicit cal to kernelspec unless python wheels enable some relocation capabilities.

[bollwyvl]

python wheels enable some relocation capabilities.

not holding my breath on that one... i think we close this one out, as such a significant upstream change will no doubt cause other issues.

A bigger thing upstream is platform-dependent paths in JSON: i don't know how conda would handle rewriting them, but i'm beginning to think the kernelspec should initially enable, and then eventually require full (normalized) URIs, even for local paths... getting said full URIs can be peril-fraught, especially (surprise) on windows (UNC, normalized case for drives letters, etc). But it's a standard, and plays nice with JSON.