bug#30921: Jupyter uses the wrong Python.

bug#30921: Jupyter uses the wrong Python.

[Fis Trivial]

When running jupyter, it seems that the python in "/usr/bin/python"
instead of the one in store is used. Here is the complete logging of
jupyter console output, notice those line in the middle, where displaying:
"/usr/bin/python: No module named ipykernel_launcher"

--
/gnu/store/k2y0d2rp57pnl90lxqgs5i7ywywrn456-python-traitlets-4.2.0/lib/python3.6/site-packages/traitlets/config/configurable.py:74: RuntimeWarning: Passing unrecoginized arguments to super(ConfigManager).__init__(config_dir='/home/fis/.jupyter/nbconfig').
object.__init__() takes no parameters
This error will be raised in a future release of traitlets.
  super(Configurable, self).__init__(**kwargs)
[I 14:48:57.236 NotebookApp] Serving notebooks from local directory: /home/fis/Others/git-repos/machine-learning/AIMA/aima-python
[I 14:48:57.237 NotebookApp] 0 active kernels 
[I 14:48:57.237 NotebookApp] The Jupyter Notebook is running at: http://localhost:8888/
[I 14:48:57.237 NotebookApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[W 14:49:11.606 NotebookApp] Notebook mdp.ipynb is not trusted
[W 14:49:11.638 NotebookApp] 404 GET /nbextensions/widgets/notebook/js/extension.js?v=20180324144856 (::1) 5.27ms referer=http://localhost:8888/notebooks/mdp.ipynb
[W 14:49:11.919 NotebookApp] Deprecated files/ URL: files/images/mdp-a.png
[I 14:49:11.920 NotebookApp] 302 GET /notebooks/files/images/mdp-a.png (::1) 1.02ms
[I 14:49:12.687 NotebookApp] 302 GET /notebooks/images/grid_mdp.jpg (::1) 0.90ms
[I 14:49:12.689 NotebookApp] 302 GET /notebooks/images/grid_mdp_agent.jpg (::1) 0.88ms
[I 14:49:12.955 NotebookApp] 302 GET /notebooks/images/-0.04.jpg (::1) 0.87ms
[I 14:49:13.023 NotebookApp] 302 GET /notebooks/images/-0.4.jpg (::1) 0.89ms
[I 14:49:13.124 NotebookApp] 302 GET /notebooks/images/-4.jpg (::1) 0.89ms
[I 14:49:13.210 NotebookApp] 302 GET /notebooks/images/4.jpg (::1) 0.91ms
[I 14:49:13.264 NotebookApp] 302 GET /notebooks/images/ge0.jpg (::1) 0.89ms
[I 14:49:13.265 NotebookApp] 302 GET /notebooks/images/ge1.jpg (::1) 0.80ms
[I 14:49:13.266 NotebookApp] 302 GET /notebooks/images/ge4.jpg (::1) 0.77ms
[I 14:49:13.267 NotebookApp] 302 GET /notebooks/images/ge2.jpg (::1) 0.77ms
[I 14:49:13.298 NotebookApp] Kernel started: 9d5e4be9-15e1-488d-b1a2-408c229eb83c
/usr/bin/python: No module named ipykernel_launcher
[W 14:49:13.386 NotebookApp] 404 GET /static/components/MathJax/jax/element/mml/optable/BasicLatin.js?rev=2.6.0 (::1) 1.79ms referer=http://localhost:8888/notebooks/mdp.ipynb
[I 14:49:16.299 NotebookApp] KernelRestarter: restarting kernel (1/5)
/usr/bin/python: No module named ipykernel_launcher
[I 14:49:19.305 NotebookApp] KernelRestarter: restarting kernel (2/5)
/usr/bin/python: No module named ipykernel_launcher
[I 14:49:22.314 NotebookApp] KernelRestarter: restarting kernel (3/5)
/usr/bin/python: No module named ipykernel_launcher
[W 14:49:23.474 NotebookApp] Timeout waiting for kernel_info reply from 9d5e4be9-15e1-488d-b1a2-408c229eb83c
[I 14:49:25.324 NotebookApp] KernelRestarter: restarting kernel (4/5)
WARNING:root:kernel 9d5e4be9-15e1-488d-b1a2-408c229eb83c restarted
/usr/bin/python: No module named ipykernel_launcher
[W 14:49:28.337 NotebookApp] KernelRestarter: restart failed
[W 14:49:28.337 NotebookApp] Kernel 9d5e4be9-15e1-488d-b1a2-408c229eb83c died, removing from map.
ERROR:root:kernel 9d5e4be9-15e1-488d-b1a2-408c229eb83c restarted failed!
[W 14:49:28.359 NotebookApp] Kernel deleted before session
[W 14:49:28.360 NotebookApp] 410 DELETE /api/sessions/d6e551c2-84d2-4de4-bb25-1db37e4763c4 (::1) 1.22ms referer=http://localhost:8888/notebooks/mdp.ipynb
--


I'm currently running guix on top of fedora 27 x86_64, for guix version:
$ guix --version

guix (GNU Guix) 282e48eae92b1988fc7fddbf206030ccf1623728
Copyright (C) 2018 the Guix authors
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

bug#30921: Jupyter uses the wrong Python.

[Ricardo Wurmus]

Fis Trivial <ybbs.daans@hotmail.com> writes:

> When running jupyter, it seems that the python in "/usr/bin/python"
> instead of the one in store is used. Here is the complete logging of
> jupyter console output, notice those line in the middle, where displaying:
> "/usr/bin/python: No module named ipykernel_launcher"

I wonder if that’s by design.  As far as I understand Jupyter can be
used with many different kernels, including different versions of
Python.  This means that we may not limit it to just a single version of
Python at build time.

Is this correct?

I do agree, though, that the default doesn’t seem right.  As long as a
user can override the kernel to use a different Python than the one we
configured at build time, I think we should default to the current
version of Python in Guix.

--
Ricardo

GPG: BCA6 89B6 3655 3801 C3C6  2150 197A 5888 235F ACAC
https://elephly.net

bug#30921: Jupyter uses the wrong Python.

[Fis Trivial]

Ricardo Wurmus writes:

> Fis Trivial <ybbs.daans@hotmail.com> writes:
>
>> When running jupyter, it seems that the python in "/usr/bin/python"
>> instead of the one in store is used. Here is the complete logging of
>> jupyter console output, notice those line in the middle, where displaying:
>> "/usr/bin/python: No module named ipykernel_launcher"
>
> I wonder if that’s by design.  As far as I understand Jupyter can be
> used with many different kernels, including different versions of
> Python.  This means that we may not limit it to just a single version of
> Python at build time.
>
> Is this correct?
>

Actually the only command I know about jupyter is how to open a
notebook :) . But it asks me to restart the kernel again and again in
browser. And according to the console, it seems that jupyter couldn't
find the needed kernel because the kernel is installed in guix store,
not in normal system path, but jupyter itself is ran by system
python other than the one installed in guix store.

And, maybe I am wrong, packages that installed by guix should never use
software not in the store, right?


> I do agree, though, that the default doesn’t seem right.  As long as a
> user can override the kernel to use a different Python than the one we
> configured at build time, I think we should default to the current
> version of Python in Guix.

bug#30921: Jupyter uses the wrong Python.

[Konrad Hinsen]

Ricardo Wurmus <rekado@elephly.net> writes:

> I wonder if that’s by design.  As far as I understand Jupyter can be
> used with many different kernels, including different versions of
> Python.  This means that we may not limit it to just a single version of
> Python at build time.
>
> Is this correct?

Yes. Installed kernels are normally under $prefix/share/jupyter/kernels.
A standard installation of Jupyter via PyPI also installs a kernel for
the same Python interpreter that is used for Jupyter. Additional kernels
can then be installed afterwards.


Fis Trivial <ybbs.daans@hotmail.com> writes:

> Actually the only command I know about jupyter is how to open a
> notebook :) . But it asks me to restart the kernel again and again in
> browser. And according to the console, it seems that jupyter couldn't

You could run

   jupyter kernelspec list

to see which kernels Jupyter actually uses.

Konrad.

bug#30921: Jupyter uses the wrong Python.

[Ludovic Courtès]

Hello,

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> Ricardo Wurmus <rekado@elephly.net> writes:
>
>> I wonder if that’s by design.  As far as I understand Jupyter can be
>> used with many different kernels, including different versions of
>> Python.  This means that we may not limit it to just a single version of
>> Python at build time.
>>
>> Is this correct?
>
> Yes. Installed kernels are normally under $prefix/share/jupyter/kernels.
> A standard installation of Jupyter via PyPI also installs a kernel for
> the same Python interpreter that is used for Jupyter. Additional kernels
> can then be installed afterwards.

So my understanding is that there’s no bug on our side, right?

Thanks,
Ludo’.

bug#30921: Jupyter uses the wrong Python.

[Konrad Hinsen]

ludo@gnu.org (Ludovic Courtès) writes:

>> Yes. Installed kernels are normally under $prefix/share/jupyter/kernels.
>> A standard installation of Jupyter via PyPI also installs a kernel for
>> the same Python interpreter that is used for Jupyter. Additional kernels
>> can then be installed afterwards.
>
> So my understanding is that there’s no bug on our side, right?

That depends on what you call a bug.

The current behavior of the Guix package for Jupyter is not in conflict
with any written documentation for Jupyter, but does not respect a
convention that standard installations (via pip, for example) do
respect. This convention says that the default Python kernel for Jupyter
uses the same Python installation as Jupyter itself.

I'd vote for respecting this convention, and I'd be happy to work on an
implementation, but don't count on me for this before August.

Konrad.

bug#30921: Jupyter uses the wrong Python.

[Ludovic Courtès]

Konrad Hinsen <konrad.hinsen@fastmail.net> skribis:

> ludo@gnu.org (Ludovic Courtès) writes:
>
>>> Yes. Installed kernels are normally under $prefix/share/jupyter/kernels.
>>> A standard installation of Jupyter via PyPI also installs a kernel for
>>> the same Python interpreter that is used for Jupyter. Additional kernels
>>> can then be installed afterwards.
>>
>> So my understanding is that there’s no bug on our side, right?
>
> That depends on what you call a bug.
>
> The current behavior of the Guix package for Jupyter is not in conflict
> with any written documentation for Jupyter, but does not respect a
> convention that standard installations (via pip, for example) do
> respect. This convention says that the default Python kernel for Jupyter
> uses the same Python installation as Jupyter itself.

Oh, got it.

> I'd vote for respecting this convention, and I'd be happy to work on an
> implementation, but don't count on me for this before August.

Alright, we’ll see!

Thanks for the explanation,
Ludo’.