I'm trying to get IpyVolume up and running on my laptop, which I was able to do successfully on my desktop. Also, a fresh userspace has no problem.
Specs for my desktop system (full pip freeze). This setup works fine.
ipyvolume==0.2.3
ipywidgets==6.0.0b10
widgetsnbextension==2.0.0b19
However, on this system (laptop), ipyvolume.volshow(hdz.data) raises
The installed widget Javascript is the wrong version. It must satisfy the semver range ~2.1.4.
and shows nothing.
System specs:
Ubuntu 16.04
Python 3.5.2
Pip 9.0.1
ipyvolume==0.2.3
ipywidgets==6.0.0
Pip freeze out:
appdirs==1.4.2
bleach==1.5.0
decorator==4.0.11
entrypoints==0.2.2
html5lib==0.9999999
ipykernel==4.5.2
ipython==5.3.0
ipython-genutils==0.1.0
ipyvolume==0.2.3
ipywidgets==6.0.0
Jinja2==2.9.5
jsonschema==2.6.0
jupyter-client==5.0.0
jupyter-core==4.3.0
MarkupSafe==0.23
mistune==0.7.3
nbconvert==5.1.1
nbformat==4.3.0
notebook==4.4.1
numpy==1.12.0
olefile==0.44
packaging==16.8
pandas==0.19.2
pandocfilters==1.4.1
pexpect==4.2.1
pickleshare==0.7.4
Pillow==4.0.0
prompt-toolkit==1.0.13
ptyprocess==0.5.1
Pygments==2.2.0
pyparsing==2.1.10
python-dateutil==2.6.0
pytz==2016.10
pyzmq==16.0.2
simplegeneric==0.8.1
six==1.10.0
terminado==0.6
testpath==0.3
tornado==4.4.2
traitlets==4.3.2
traittypes==0.0.6
wcwidth==0.1.7
widgetsnbextension==2.0.0
Steps to reproduce:
Fresh python3 virtualenv
pip install ipywidgets
pip install ipyvolume
jupyter nbextension enable --py --sys-prefix widgetsnbextension
jupyter nbextension enable --py --sys-prefix ipyvolume
jupyter notebook
then run the default hdz from ipyvolume tutorial.
import ipyvolume
hdz = ipyvolume.datasets.hdz2000.fetch()
ipyvolume.volshow(hdz.data)
Workarounds attempted:
pip install --upgrade ipywidgets==6.0.0b10 - just changes the Semver that it asks for..jupyter .ipython and .ipyvolume because I thought there may be a config file hiding in there causing stuff to goof. No dice. ~/.local/shared/jupyter also got rid of the problem. Actually the culprit seems to be So there is something there which is causing SNAFU. ~/.local/shared/jupyter/nbextensions, which contains some .js files, resolves the problem and seems to cause no other conflicts. Related issues:
https://github.com/ipython/ipywidgets/issues/662
Assorted Thoughts:
I've noticed before that Jupyter has a tendency to "leak" out of virtualenvs. I have some other npm stuff sitting on this system, and I wonder if they could be interfering. Might retry with a new userspace. Since fresh user install works with no hitches, I think this strengthens my "jupyter environment is leaking" theory. But I am not sure how to rectify that.
Should I raise this issue on the IPyvolume repo as well?
Deleting the folder ~/.local/share/jupyter/nbextensions resolves the problem. However, it took me an hour of poking around, going off of a rather cryptic error message, to get to this point. It's not clear to me where that file came from or why it is interfering.
It might be nice to add a note in that error message that local config files may interfere with the widgets extension.
Thanks, this issue of config files overriding other config files has been a confusing thing even for us! Let's start a FAQ with things like this in the docs. It's not just widgets, it's a general notebook extension problem.
How integrated is Jupyter development with the virtualenv project? In my brutally honest opinion, virtualenv should automatically set the Jupyter configuration path variables if I pip instally jupyter from within a VE. Since I am installing Jupyter into the VE, any non-VE behavior of Jupyter (such as these config conflicts) is quite surprising. But I'm not sure how that would fire off.
@prefrontalvortex sorry for the late reply. I agree that the current jupyter extension mechanism is the source of a lot of pain. However, this is an issue with the notebook server project more than ipywidgets. In fact, we have made a Jupyter enhancement proposal for new semantics for extensions
--sys-prefix for installing or enabling extension. Warning loudly when users install or enables extensions with --user.Whith these changes, we should be better off than in the current situation. This is mostly a matter of one of us allocating the necessary cycles to the implementation.
Closing as this is resolved.
Whenever I try to plot Google Maps on Jupyter notebooks, this error pops up. I have already deleted all the nbextensions folders, however the error persists.
Is there any other workaround?
Thank you.
Can you tell us what extensions you have installed, as well as what version of ipywidgets and widgetsnbextension you have installed? Can you also send the output of jupyter nbextension list?
jupyter --paths should give you all of the data directories that jupyter is looking into - those are places to look for the nbextension folders. The config directories listed are the places to see what extensions are enabled.
By the way, I'm deleting these checks in https://github.com/ipython/ipywidgets/pull/1219 since the actual check mechanism is error-prone.
For no reason that I could figure out, I started receiving this warning this morning. In addition the widgets would no longer appear. After a lot of experimentation, I repaired the issue by deleting the virtualenv, recreating it, and then reinstalling all my dependencies from requirements.txt.
I'm up and running again, but I have no idea why that worked.
Also hitting this error when trying to work with widgets.
data:
/home/myuser/.local/share/jupyter
/home/myuser/BAYESOPT/MOE-BO/envs/py3moboenv/share/jupyter
/usr/local/share/jupyter
/usr/share/jupyter
Same here... went through and deleted all nbextension folders I could find (on a Mac with Homebrew, so ~/Library/Jupyter ./.ipython/nbextensions and ./share/jupyter/nbextensions all existed). No dice. 😭
Most helpful comment
@prefrontalvortex sorry for the late reply. I agree that the current jupyter extension mechanism is the source of a lot of pain. However, this is an issue with the notebook server project more than ipywidgets. In fact, we have made a Jupyter enhancement proposal for new semantics for extensions
--sys-prefixfor installing or enabling extension. Warning loudly when users install or enables extensions with--user.Whith these changes, we should be better off than in the current situation. This is mostly a matter of one of us allocating the necessary cycles to the implementation.