WINDOWS: problem with kernel.json wrong path

[kmuehlbauer]

Users reported problems with a fresh conda environment while running:

> jupyter notebook --ip=127.0.0.1

The kernel died immediately with some Windows error message: [Error2] System cannot find file (translated from german).

This can be fixed by getting the kernelspec file via:

> jupyter kernelspec list

and deleting the kernel.json at the displayed path.

I quickly checked the conda-forge ipykernel archives and the default one. The only difference: In the conda-forge there is another folder share which has the kernelspec json-file inside.

But the path within the json file is wrong also after installation:

{
 "display_name": "Python 2", 
 "language": "python", 
 "argv": [
  "C:\\conda\\envs\\_build\\python.exe", 
  "-m", 
  "ipykernel", 
  "-f", 
  "{connection_file}"
 ]
}

I'm not sure, how this should work, but this path should be changed to the correct location while installing ipykernel-package.

[kmuehlbauer]

@minrk Any thoughts?

[minrk]

How do conda and conda-build identify the magic paths that should be patched on package/install? We should make sure that happens on kernel.json.

[minrk]

It would appear that the patch is applying correctly on non-Windows, so maybe there's something wrong with how conda-build detects the _build path on Windows, such that it doesn't find it.

[kmuehlbauer]

ping @gillins Could you please have look into this? The kernelspec file is delivered with the package, but the _build-path isn't changed accordingly when installing.

[pelson]

Agreed. Sounds more like a conda-build bug than anything else. I have confirmed this with our py27, py34 and py35 builds - they all have the same issue. Ping @msarahan - are you aware of any such issue?

I have a PR (#7) which adds a test for the prefix in the kernel.json, and hopefully a fix for the actual problem (defining has_prefix_files explicitly).

[msarahan]

Reminder here: when conda-build 1.21.0 is released, this feedstock just needs to be rebuilt, and the prefix replacement stuff should work.

I'll test that in a PR here.

Build number bump for rebuild?

[ocefpaf]

@conda-forge/ipykernel the binaries on the channel were caused havoc in my last meeting when people tried to install jupyter. I removed the binaries for now to ensure that the default channel version will be picked up. I know that was a harsh solution, but I cannot tell ~40 to pin their ipykernel to 4.2.2 😉

xref: ContinuumIO/anaconda-issues#813 (comment)

Ping @rsignell-usgs. You can try the environment.yml again with conda-forge enabled.

[pelson]

Given the ipkernel distribution was completely broken I think that is a reasonable solution @ocefpaf. We all know it is preferable to fix the problem, but in the situation where we don't have the full solution yet, we are certainly better off ensuring that it works for our users.

[rsignell-usgs]

It works! (Creating the IOOS environment with environment.yml)