Forums

I see up my virtual env for iPython following the instructions (here), but it's not working. When I open up an iPython notebook (either new or existing), I do see the virtualenv as an available kernel. But when I switch to it, the kernel immediately dies and I get this message:

The kernel has died, and the automatic restart has failed. It is possible the kernel cannot be restarted. If you are not able to restart the kernel, you will still be able to save the notebook, but running code will no longer work until the notebook is reopened

I've tried quitting all processes, but it doesn't seem to have made a difference.

I did get a warning when I was installing prompt-toolkit in the virtualenv, that the version (1.0.15) is lower than what is required. I'm not sure if that's related to the problem. Even if it is, I'm not sure how to fix it because I tried installing the higher version (3.something) of prompt-toolkit outside of the virtualenv, and that gave a warning as well that the version did not match requirements. (So I rolled it back to 1.0.15).

The combination of versions in the virtual environment has to match. What versions were you running?

I just have the default ones for the earlgray profile:

pip3.7 show:

• Name: tornado, Version: 4.5.3
• Name: ipykernel, Version: 4.8.2
• Name: prompt-toolkit, Version: 1.0.15

I installed the exact same versions in my virtualenv:

(env37) 16:26 ~ $ pip show tornado ipykernel prompt-toolkit
Name: tornado
Version: 4.5.3
...
---
Name: ipykernel
Version: 4.8.2
...
---
Name: prompt-toolkit
Version: 1.0.15
...

When I installed prompt-toolkit 1.0.15 in the virtualenv, though, it installed successfully but gave me this warning:

ERROR: pip's dependency resolver does not currently take into account a ll the packages that are installed. This behaviour is the source of the following dependency conflicts. ipython 7.28.0 requires prompt-toolkit!=3.0.0,!=3.0.1,<3.1.0,>=2.0.0, b ut you have prompt-toolkit 1.0.15 which is incompatible.

But, again, I don't know if this is the source of the problem with the kernel or not. The iPython notebooks work fine in the non-virtualenv 3.7, which also has 1.0.15.

Realized something when writing that out: the version of iPython in the virtualenv (7.28.0) is different than outside it (4.1.2). Should I upgrade my iPython?

You need to version of the packages in your virtualenv to be the same as the version outside. Since you have IPython 7.28.0 installed into the virtualenv, you need to downgrade it to 4.1.2.

Ah. They should add checking the iPython version to the instructions.

Unfortunately, that didn't solve the problem — I still get a dead kernel in the virtualenv iPython.

Could you copy/paste the output of pip freeze in the virtualenv into a post here? Then we can check just in case there's another non-obvious package that needs to be pinned to something different.

Here you go!

(env37) 20:02 ~ $ pip freeze
backcall==0.2.0
cachetools==4.2.4
camel-kenlm==2020.11.2
camel-tools==1.2.0
certifi==2021.5.30
charset-normalizer==2.0.6
click==8.0.1
decorator==5.1.0
dill==0.3.4
docopt==0.6.2
editdistance==0.5.3
entrypoints==0.3
filelock==3.3.0
future==0.18.2
huggingface-hub==0.0.18
idna==3.2
importlib-metadata==4.8.1
ipykernel==4.8.2
ipython==4.1.2
jedi==0.18.0
joblib==1.0.1
jupyter-client==7.0.6
jupyter-core==4.8.1
matplotlib-inline==0.1.3
nest-asyncio==1.5.1
threadpoolctl==3.0.0
numpy==1.21.2
packaging==21.0
pandas==1.1.5
parso==0.8.2
pexpect==4.8.0
pickleshare==0.7.5
prompt-toolkit==1.0.15
ptyprocess==0.7.0
Pygments==2.10.0
pyparsing==2.4.7
python-dateutil==2.8.2
pytz==2021.3
PyYAML==5.4.1
pyzmq==22.3.0
regex==2021.9.30
requests==2.26.0
ruamel.yaml==0.17.16
ruamel.yaml.clib==0.2.6
sacremoses==0.0.46
scikit-learn==1.0
scipy==1.7.1
simplegeneric==0.8.1
six==1.16.0
threadpoolctl==3.0.0
tokenizers==0.10.3
torch==1.9.1
tornado==4.5.3
tqdm==4.62.3
traitlets==5.1.0
transformers==4.11.2
typing-extensions==3.10.0.2
urllib3==1.26.7
wcwidth==0.2.5
zipp==3.6.0

That looks good. Use the "Fetch process list" button on the Consoles page to get a list of processes and kill the ones that mention "jupyter", "sudospawner", or "kernel". Then try re-opening your notebook.

Yeah, I already tried that multiple times and it doesn't work. :-(

I still see jupyter processes running in your account since 2021-10-06 -- are you sure you killed all of them?

Yeah, I killed them all before I posted this. (I had seen that recommendation in previous posts.) I just tried again though, and am still getting a dead kernel.

Ok. Let's try eliminating things. Can you try a virtualenv with only the required packages for a working iPython? Also, can you confirm that you have tried this in existing notebooks and newly-created notebooks?

Okay, I created a fresh virtualenv, (called "test") and only installed the tornado, ipykernel, and prompt-toolkit. (And I downgraded the iPython version, as we discussed above.) I closed out all running processes, then tried it in an existing iPython notebook. Dead kernel. I created a new iPython notebook and tried the 'test' kernel. Dead kernel.

I noticed something, though. The process that's running with the iPython notebooks is:

/usr/local/bin/python3.4 /usr/bin/jupyterhub-singleuser --user=larapsodia --port=42937 --cookie-name=jupyter-hub-token-larapsodia --base-url=/user/larapsodia --hub-prefix=/hub/ --hub-api-url=http://127.0.0.1:8081/hub/api --ip=localhost --debug

Why does it say python3.4? The virtualenv and the iPython notebook were all 3.7. (My main website and most of my code was done in 3.4, but I recently upgraded my system image from classic to earlgrey so I could start transitioning everything to 3.7.)

I bet this is the source of the problem, but I don't know how to fix it.

We will take a look on Monday.

The Python 3.4 is normal -- the way Jupyter notebooks work is that you have one central "hub" process, which spawns off the kernels and handles the communication between them and the browser. We use 3.4 for that one for historical reasons.

Can we take a look at your files? We can see them from our admin interface, but we always ask for permission first. In particular I'd like to take a look at your new "test" virtualenv.

Yes, that's fine.

In your experiments with the new virtualenv, did you kill all the notebook-related processes before starting each of those notebooks?

Yes

Sorry about the long turnaround on this. It looks like the problem is that you're on an old system image; we weren't aware of this, but the instructions for creating a virtualenv that is compatible with Jupyter only work if you're on our most recent image, "glastonbury". I'll update the help page to reflect that.

You can easily change your system image -- your files and data would be safe, as it would essentially just upgrade all of the operating system packages -- and doing so would have the advantage of giving you access to newer versions of Python and of the pre-installed Python packages. But you might have to rebuild any virtualenvs that you currently have so that they're compatible with the newer Python versions. There's more information on this help page.

Again, sorry that it took so long for us to work out what the problem was here!