Closed alexhrescale closed 5 years ago
Hi @alexhrescale, thank you for being interested in my work. If you want to try it quickly, please consider using Dockerfile
.
Please look the latest passing CI logs, which creates the minimal working environment with pip install
command:
https://gitlab.com/m-ueno/sshkernel/-/jobs/274535122
...
Successfully installed MarkupSafe-1.1.1 PyYAML-5.1.2 asn1crypto-0.24.0 backcall-0.1.0 bcrypt-3.1.7 bleach-3.1.0 cffi-1.12.3 cryptography-2.7 decorator-4.4.0 defusedxml-0.6.0 entrypoints-0.3 ipykernel-5.1.2 ipyparallel-6.2.4 ipython-7.7.0 ipython-genutils-0.2.0 jedi-0.15.1 jinja2-2.10.1 jsonschema-3.0.2 jupyter-client-5.3.1 jupyter-core-4.5.0 metakernel-0.24.2 mistune-0.8.4 nbconvert-5.6.0 nbformat-4.4.0 pandocfilters-1.4.2 paramiko-2.6.0 parso-0.5.1 pexpect-4.7.0 pickleshare-0.7.5 plumbum-1.6.7 prompt-toolkit-2.0.9 ptyprocess-0.6.0 pycparser-2.19 pygments-2.4.2 pynacl-1.3.0 pyrsistent-0.15.4 python-dateutil-2.8.0 pyzmq-18.1.0 sshkernel-0.9.1 testpath-0.4.2 tornado-6.0.3 traitlets-4.3.2 wcwidth-0.1.7 webencodings-0.5.1
It looks you have old version of sshkernel==0.6.1. How about uninstalling/upgrading sshkernel? Or, how about recreating virtual environments and install it with clean dependency?
Thanks for your reply. I am running in a clean virtualenv (via nix sandbox), and by default, it installs sshkernel==0.9.1
, which did not work. Due to #13 I am suspecting there may be regressions in other libraries even in patch version updates.
I have tried the Dockerfile approach, and it works, but I would also like to be able to add sshkernel to an existing jupyter notebook setup. I will use the Docker version as a starting point to find the divergence.
I have a suspicion that the base libraries that are provided from a conda install are the source of the divergence. For the record, these libraries are installed on a fresh Miniconda (conda 4.7.10
) install
- _libgcc_mutex==0.1=main
- asn1crypto==0.24.0=py37_0
- bzip2==1.0.8=h7b6447c_0
- ca-certificates==2019.5.15=0
- certifi==2019.6.16=py37_0
- cffi==1.12.3=py37h2e261b9_0
- chardet==3.0.4=py37_1
- conda-package-handling==1.3.11=py37_0
- conda==4.7.10=py37_0
- cryptography==2.7=py37h1ba5d50_0
- idna==2.8=py37_0
- libarchive==3.3.3=h5d8350f_5
- libedit==3.1.20181209=hc058e9b_0
- libffi==3.2.1=hd88cf55_4
- libgcc-ng==9.1.0=hdf63c60_0
- libstdcxx-ng==9.1.0=hdf63c60_0
- libxml2==2.9.9=hea5a465_1
- lz4-c==1.8.1.2=h14c3975_0
- lzo==2.10=h49e0be7_2
- ncurses==6.1=he6710b0_1
- openssl==1.1.1c=h7b6447c_1
- pip==19.1.1=py37_0
- pycosat==0.6.3=py37h14c3975_0
- pycparser==2.19=py37_0
- pyopenssl==19.0.0=py37_0
- pysocks==1.7.0=py37_0
- python-libarchive-c==2.8=py37_11
- python==3.7.3=h0371630_0
- readline==7.0=h7b6447c_5
- requests==2.22.0=py37_0
- ruamel_yaml==0.15.46=py37h14c3975_0
- setuptools==41.0.1=py37_0
- six==1.12.0=py37_0
- sqlite==3.29.0=h7b6447c_0
- tk==8.6.8=hbc83047_0
- tqdm==4.32.1=py_0
- urllib3==1.24.2=py37_0
- wheel==0.33.4=py37_0
- xz==5.2.4=h14c3975_4
- yaml==0.1.7=had09818_2
- zlib==1.2.11=h7b6447c_3
- zstd==1.3.7=h0b5b093_0
Here are steps to get it running, from outside the docker container.
pip freeze > jovyan.txt
from a fresh conda env, run for dep in $(cat jovyan.txt); do pip install $dep --force-reinstall --no-cache; done
. This has 2 effects:
distutils
cannot be removed (it says distutils but is most likely the conda-provided version).Note that from within a conda env, the stalling in #13 is not observed. The SSH notebook launches and the kernel launches (but I cannot get the SSH to connect, observed in #15).
Thus, as of now, it would appear that successful use of this library requires conda.
Hmm, I think it doesn't require conda.
My develop environment on Ubuntu 18.04 is created with pyenv
not conda.
Another user successfully running it on Ubuntu 18.10 with OS bundled python https://packages.ubuntu.com/cosmic/python3 .
Recent passing continuous integration tests run without conda (see https://hub.docker.com/_/python) .
As described in #15, it also works within a conda env.
By the way, I'll add more information about the working environment to README
.
I'm closing this issue because #16 add information about the working environment to README
.
If you still have trouble, please open a new issue.
Can you please share the minimal working environment that you use for the examples?
Currently, I am running with this environment
The library versions of the dependencies should be matching the lowest working versions as declared in requirements.txt. I installed them using
pip install -r reqs.txt
where reqs.txt containswhere every
>=
version is replaced with==
. In a blank ipython notebook with theSSH
kernel, it fails with e.g.Another check is by running
from one terminal in the venv, then running e.g.
in another terminal that uses the same venv. This fails with
Thanks for your help