auto enable nbextension when installing with pip

[maartenbreddels]

This will enable rise for notebook >= 5.3. I do see a 404 for rise.css, i'm not sure that is ok.

[maartenbreddels]

see jupyter/notebook#3116 for the changes that made this possible.

[damianavila]

Great, I was thinking about this the other day... some comments:

1. We need to update the requirements here and here, because we need notebook >= 5.3.

2. The postscripts step in the current conda recipe should be deleted, they are no longer necessary.

I do see a 404 for rise.css, I'm not sure that is ok.

That's OK. Not a problem.

[maartenbreddels]

What most of the widgets do, is to keep the old method, and wait say a year until many people have moved. Another issue is that if the unlink script gets called, the extension is disabled, never to be abled again (it will override the defaults provided by this mechanism).

[damianavila]

What most of the widgets do, is to keep the old method, and wait say a year until many people have moved.

For those widgets, the new conda packages will be enabled by default when the build script is run (or the script cmd in the recipe), but then it is enabled again with the post-link? How do you solve that inconsistency?

Another issue is that if the unlink script gets called, the extension is disabled, never to be abled again (it will override the defaults provided by this mechanism).

I do not understand how the unlink script could give you problem if it is not there... can you explain me a little bit more? Thanks!!

[maartenbreddels]

{prefix}/etc/jupyter/nbconfig/notebook.json contains what is enabled/disabled by jupyter nbextension .... The files in {prefix}/etc/jupyter/nbconfig/notebook.d/*.json contain what you can see as defaults, but the notebook.json overrides these, it it exists.
If the unlink script executes jupyter nbextension disable ..., it will leave in notebook.json the following:

{
  "load_extensions": {
    "ipyvolume/extension": false
  }
}

If after installing the new version (of say ipyvolume) which will add a file to the .d directory, it will not be enabled, since the settings of the json file takes precedence over the values from the .d directory.

I think the unlink script actually should not execute disable, since it does not leave an environment in the state it was in before the package was installed.
We should actually think how we're gonna solve this (cc @jasongrout).

In short, it doesn't hurt to merge this PR, it will make people using pip happy, but for the conda-forge users we cannot removed the link/unlink scripts yet.

[damianavila]

{prefix}/etc/jupyter/nbconfig/notebook.json contains what is enabled/disabled by jupyter nbextension .... The files in {prefix}/etc/jupyter/nbconfig/notebook.d/*.json contain what you can see as defaults, but the notebook.json overrides these, it it exists.

Oh, now it makes sense.

If after installing the new version (of say ipyvolume) which will add a file to the .d directory, it will not be enabled, since the settings of the json file takes precedence over the values from the .d directory.

Got it! Thanks for the additional explanation.

I think the unlink script actually should not execute disable, since it does not leave an environment in the state it was in before the package was installed.
We should actually think how we're gonna solve this (cc @jasongrout).

Interesting discussion...

In short, it doesn't hurt to merge this PR, it will make people using pip happy, but for the conda-forge users we cannot removed the link/unlink scripts yet.

Understood.

Still, this comment is pertinent, I think:

We need to update the requirements here and here, because we need notebook >= 5.3.

[parmentelat]

being a pip user myself, I would love this PR to make it in the next release

I can propose to handle the impact on the doc once the new one is on.

Also about the 404 that triggers concerning rise.css: this is sort of expected; the way we deal with ad hoc css (rise.css and thenotebookname.css) is to blindly try to load them into the browser, regardless of whether they exist or not; in other words I was not able to figure out a proper way to compute whether these files indeed are present or not - which would have been less sloppy because the 404 message of course can be alarming.

[damianavila]

being a pip user myself, I would love this PR to make it in the next release

It is the idea to include it.

I can propose to handle the impact on the doc once the new one is on.

Thanks.

Also about the 404

Not a big deal for now, I think.

[maartenbreddels]

We need to update the requirements here and here, because we need notebook >= 5.3.

We don't do this for ipywidget, ipyvolume, threejs or bqplot (AFAIK). We just mention that you still need to run this when you have < 5.3.
What do you think?

[damianavila]

What do you think?

That's ok, I guess... let's do the same than the other lib does.
Btw, I need to test this one before merging. Will do it soon.
Thanks!

[maartenbreddels]

Thanks you for this great extension!

[damianavila]

I could finally test this one and looks good. Merging now and sorry for the delay!