Provide better feedback for "The installed widget Javascript is the wrong version" message

[fperez]

I am getting this message again after doing an update, and I'm a bit stumped on how to debug it. In the past @SylvainCorlay has helped me manually, but I've also seen others stuck with the same issue. We should make that message carry some extra information that can at least point the user in the direction of how to try to resolve it...

[fperez]

I should add that the problem persists on an install from master of ipywidgets + notebook, even after doing a full git clean -fdx and re-running the dev install process as per the instructions (using the dev-install.sh script).

Everything I've tested seems to work ok, but it's annoying to get that message...

[minrk]

Last I saw this, it seemed like it could be a race in the check, where the check could happen before the info had propagated. I haven't been able to track it down, though.

[hainm]

I got the same issue: getting the message but still able to view the widget

[fperez]

I just got it in the same session for a drop-list widget but not for a checkbox. Same notebook, kernel, etc, just two cells in succession, the check-box one doesn't show the warning, the drop-menu (with a [list] argument) does.

I'm sure this makes sense to someone, but I find it rather disconcerting.

[jasongrout]

Just checking, what release (or what commit if a dev install) of ipywidgets and of the notebook are you two running?

[fperez]

Master all the things!!

(master)Kerbin[ipywidgets]> git slog | head
*   8915631 Merge pull request #678 from willingc/update-build

(master)Kerbin[notebook]> git slog | head
*   7607db4 Merge pull request #1603 from minrk/rm-docker-readme

(master)Kerbin[jupyterlab]> git slog | head
*   ee3d32b Merge pull request #465 from danielballan/dragable-output-cleanup

And all these are dev installs:

In [11]: import ipywidgets, notebook, jupyterlab

In [12]: ipywidgets.__file__
Out[12]: '/Users/fperez/dev/ipython/ipywidgets/ipywidgets/__init__.py'

In [13]: notebook.__file__
Out[13]: '/Users/fperez/dev/jupyter/notebook/notebook/__init__.py'

In [14]: jupyterlab.__file__
Out[14]: '/Users/fperez/dev/jupyter/jupyterlab/jupyterlab/__init__.py'

[fperez]

Just noting that @ngoldbaum just reported on gitter related issues, and I'm also seeing the dreaded The installed widget Javascript is the wrong version everywhere:

[SylvainCorlay]

@fperez typically, this occurs when you have another version of the javascript in one of the jupyter paths.

I am really frustrated with the current notebook extension system and ipywidgets is the project that has suffered the most from it.

I am going to put some cycles on this this week or next week. Putting the conf.d thing on the side,, here are a few things I think should be changed:

• sys-prefix install should be the default instead of system for both enabling and installing. People are confused when enabling/installing an nbextension requires different privileges from the pip install. Doing anything else than --sys-prefix should be a conscious decision. It is also important to note that --user is global to all the python installs that the user may use. (Hence --user is almost always evil).
• When installing an nbextension, --override should be True by default. Otherwise people don't know that they may have an older version of the js installed.
• Uninstalling an nbextension should also disable the nbextension.
• A major change that I want to put in place is that if nbextension is loaded because it is enabled in e.g. sys-prefix, the assets should only looked for in sys-prefix. If it is loaded because enabled in the user configuration directory, it should only load the assets in the user data directory etc...
• At the moment, disabling an extension with --user (i.e. setting it to False in the user nbconfig) will cause the extension to not be enabled even if it is enabled e.g. in sys-prefix because the user configuration has the priority - which is really silly. This problem will go when I fix the previous one.

[fperez]

Thansk @SylvainCorlay! I understand your frustration, and really appreciate your willingness to put some cycles into cleaning this up...

In the meantime: can you give me a bit more of a hint to debug the issue? If we sort it out here, it will already help others...

How can I see the paths it's loading JS from? We should also add to that error message specific path information about the conflict. That would make it easier for users to diagnose and debug the problem.

[SylvainCorlay]

You probably have some js assets in your user directory.

You can try

pip uninstall widgetsnbextension ipywidgets

jupyter nbextension uninstall --py widgetsnbextension
jupyter nbextension uninstall --py --user widgetsnbextension
jupyter nbextension uninstall --py --sys-prefix widgetsnbextension

then run the dev-install instructions

[fperez]

Thanks @SylvainCorlay! I also did a "nuclear wipe" of my git repo with git clean -fdx . and of anything with widgetsnbextension in the name in my conda directory, since at first the pip uninstall command failed for me.

But once I'd wiped everything out and reran the dev-install shell script, it now works without the warning. Hopefully these instructions will already help others. I think they should probably go into the dev-install docs, though...

[fperez]

BTW, incidentally, the full wipe/reinstall from master fixed the error message, but now layout is seriously messed up... If you compare to the screenshot I'd posted above with Tab (lucky me that I happened to precisely screenshot that :), now I get this from the same code:

The tabs are obviously mangled...

Can anyone reproduce this? It comes from the Widget Layout example notebook, last cell...

If you can see this, we'll open it as a separate issue.

[SylvainCorlay]

@fperez I have never seen anything like this.

[damianavila]

I am going to put some cycles on this this week or next week. Putting the conf.d thing on the side,, here are a few things I think should be changed:

Nice and thanks in advance!

sys-prefix install should be the default instead of system for both enabling and installing. People are confused when enabling/installing an nbextension requires different privileges from the pip install. Doing anything else than --sys-prefix should be a conscious decision. It is also important to note that --user is global to all the python installs that the user may use. (Hence --user is almost always evil).

I totally agree with you here...

When installing an nbextension, --override should be True by default. Otherwise people don't know that they may have an older version of the js installed.

Sound reasonable, in fact, in some conda-packaged nbextensions we are using --override by default.

Uninstalling an nbextension should also disable the nbextension.

I agree too, people forget about disabling and that could bring some problematic leftovers... people usually request installation and activation to be separated, but I believe in this case, one thing (uninstalltion) should cause the other (disabling) as well..

A major change that I want to put in place is that if nbextension is loaded because it is enabled in e.g. sys-prefix, the assets should only looked for in sys-prefix. If it is loaded because enabled in the user configuration directory, it should only load the assets in the user data directory etc...

mmm... not sure about this in a composite scenario, I can see a scenario where sys-prefix installed extensions provides some "common" extensions (ie, provided by anaconda distro or a conda-forge set of extensions, etc) and user installed/enabled extensions that a user wrote and want to enable in all their notebook instances without installing the extension in every environment (maybe hundreds?).

At the moment, disabling an extension with --user (i.e. setting it to False in the user nbconfig) will cause the extension to not be enabled even if it is enabled e.g. in sys-prefix because the user configuration has the priority - which is really silly. This problem will go when I fix the previous one.

That maybe should be warned? In the same scenario I described above, I can see a use case to disable one extension in all my envs without disabling it in every environment...

[SylvainCorlay]

@damianavila thanks for your feedback.

I just opened jupyter/notebook#1706 to keep track on the discussions on the matter. Do you mind copying your remarks over there?

PS: I slightly modified the point on "uninstalling an nbextension should also disable the nbextension".

[fperez]

Well @SylvainCorlay, I can confirm that I'm getting that bizarre layout on master, after a clean install and a cache flush... The above was on Chrome, and it gets even worse on Safari:

This looks like a real bug to me :)

[SylvainCorlay]

@fperez I nuked the node modules and re-installed and I can now reproduce your issue.

It seems to be due to the update of phophor. jupyter-js-widgets tabs use phosphor tabs in master...

[fperez]

For reference, further follow-up on the tabs question should happen in #733 that @SylvainCorlay just opened. This issue should focus on the JS feedback question.

Which makes me think, now that @willingc opened #732 as a docs-focused action item, it seems to me this one can be closed. Am I missing something?

[damianavila]

I just opened jupyter/notebook#1706 to keep track on the discussions on the matter. Do you mind copying your remarks over there?

Done! @SylvainCorlay

[fperez]

OK, closing here, I think we're done. Feel free to reopen if there's really a reason to keep this open on top of #732.

[ghost]

Can I append a dumb question, for those of us without root or even user access to the instance our notebook is running on; How do we silence this and remove it from view, if everything seems to be working OK?

[SylvainCorlay]

@cathalgarvey there is a precedence order for directories were the JavaScript assets are installed

system-wide < sys-prefix < user

user is global to all the sessions of that user but has a higher precedence.

You can see what the paths for this directories with jupyter --paths

• One reason why you have this warning may be that you have some wrong version installed as a user.
• Or you are running a recent version in your sys-prefix and you have an old version of the js installed system wide...

We have made proposal for better semantics for the jupyter extension mechanism that would prevent these complications, but this will be in a future major release of jupyter...

[hainm]

We have made proposal for better semantics for the jupyter extension mechanism that would prevent these complications, but this will be in a future major release of jupyter...

this will be very helpful (and eye-pleasant).

[ghost]

The above is all great, if I had any control over my notebook's underlying installation. What I was wondering, instead, is if I can disable these warnings from the browser, because I have no control over the underlying install?