Resolve problems and inconsistencies with nbextensions/serverextensions for 5.0

[ellisonbg]

I think this should block 5.0. See background:

https://groups.google.com/forum/#!topic/jupyter/PnSIeGe8VhE

[ellisonbg]

Also #1508

[ellisonbg]

Sounds like some of these things have been fixed in master, but I think the lab/nb teams should meet to go over this stuff before 5.0 is released.

[minrk]

Bringing together issues from the email:

• Unify behavior of server/nb extensions enabling, user vs sys.prefix #1508 merge inconsistencies between nbextensions and server-extensions (fixed)
• Need an option to disable extensions #1992 allow disabling extensions (fixed in jupyter-core by adding JUPYTER_NO_CONFIG)
• nbextension install output should go to stdout #1797 extension output on stdout (marked as backlog, minor style issue)
• confusing of using --py for nbextention install #1617 autocorrect for missing --py arg (marked as 5.1 as a non-blocker, but should be a small fix, if we want to change that)
• Improvement on server and notebook extension mechanism #1706 rewrite the whole extension mechanism (marked as backlog, big change)
• Add nbextension/serverextension commands for uninstall/disable all #2149 add new commands for disabling/uninstalling all extensions of a given type/scope

Two (#1797, #1617) seem to be pretty minor issues that I don't think should block 5.0.

To me, the main thing we need a decision on is #1706, which is a major reorganization of the whole extension mechanism. My understanding has been that this makes more sense to do as part of the standalone jupyter-server, rather than rewrite the extensions for 5.0 and then rewrite them again for jupyter-server. But if we want this for 5.0, we should get on it ASAP, because I think it would delay 5.0 by at least a month or two so it can have time to test in master. We could also decide to do part of it (e.g. change defaults, but not behavior), which is easier, but I'm not sure if we should do that.

[takluyver]

I'm hoping to get 5.0 out this week, so -1 to rewriting the extension system.

[blink1073]

Thank you for laying that all out, @minrk. I agree with your assessment that there should be no remaining configuration blockers to 5.0.

[blink1073]

@takluyver can go back to having his tea in peace ;).

[ellisonbg]

I agree that doing the full rewrite doesn't make sense for 5.0. We already know that we will break things in the transition to jupyter-server, so I think it makes sense to postpone all breakage until them.

[ellisonbg]

Thanks for posting the full list of everything that has been done on this front that really helps. I think the work in #1508 is the most important thing.

The only other big issue I keep running into is the need to hard delete all existing extensions of a given type (nb, server, lab) (both the extension and the config). I think a jupyter nbextension delete-all would do the trick. Probably shouldn't block 5.0 though. I will open an issue for that.

[ellisonbg]

@bollwyvl can you confirm issues on your side will be fixed by the stuff that is in master now?

[minrk]

If there are common / useful actions that are hard to do with current commands, I'm happy to add them. Is delete-all only for --py extension-providers? e.g. jupyter nbextension delete-all --py jupyterlab?

[ellisonbg]

See #2149

I was thinking they would uninstall or disable all nbextensions or server extensions in a given location (user, sys prefix, system), not just those for a single package. So I am not sure the --py flag makes sense. Although I could imagine a user wanting to delete all (user, sys prefix, system) things for a given nbextension, so maybe --py package would limit the scope of it. Let's continue the discussion on #2149

[minrk]

Gotcha, thanks!

[bollwyvl]

@ellisonbg can you confirm issues on your side will be fixed by the stuff that is in master now?

If my side is #1508... don't know! I'll give it a spin right now!

If we're talking my side being the anaconda distribution... I don't think the distribution maintainers will be happy until we have #1706 or equivalent.

[ellisonbg]

I was wanting to get a sense from the continuum/anaconda folks and you are the one following this most closely...you have answered both though ;-)

…

On Tue, Feb 7, 2017 at 11:43 AM, Nicholas Bollweg ***@***.***> wrote: @ellisonbg <https://github.com/ellisonbg> can you confirm issues on your side will be fixed by the stuff that is in master now? If my side is #1508 <#1508>... don't know! I'll give it a spin right now! If we're talking *my side* being the anaconda distribution... I don't think the distribution maintainers will be *happy* until we have #1706 <#1706> or equivalent. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0LpPXgy3dvcvVSGJ-yFV59G_E7owks5raMlegaJpZM4L45H2> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]

[bollwyvl]

Yup, it looks like #1508 is happy. Thanks all!

[bollwyvl]

Oh, and re disable-all --user... from a conda point of view, that's sounds like it will result in support tickets, but perhaps no more than the baseline. delete-all --user (and hopefully, also unset, not disable) does sound handy, but sounds extreme, so might be scary for folks. Doing that with --sys-prefix... no idea what that will be like for a conda-managed bunch of extensions. I suppose someone could just then conda install --force some-extension again.

[ellisonbg]

Good points!

…

On Tue, Feb 7, 2017 at 1:42 PM, Nicholas Bollweg ***@***.***> wrote: Oh, and re disable-all --user... from a conda point of view, that's sounds like it will result in support tickets, but perhaps no more than the baseline. delete-all --user (and hopefully, also unset, not disable) does sound handy, but *sounds* extreme, so might be scary for folks. Doing that with --sys-prefix... no idea what that will be like for a conda-managed bunch of extensions. I suppose someone could just then conda install --force some-extension again. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0HP1IHbkUrwbE2p98YgPCetfgkPiks5raOUogaJpZM4L45H2> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]

[blink1073]

Closing due to consensus that all required 5.0 actions have been made.

[ellisonbg]

Thanks everyone!

…

On Wed, Feb 8, 2017 at 6:09 AM, Steven Silvester ***@***.***> wrote: Closing due to consensus that all required 5.0 actions have been made. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#2141 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0NkZ0gaSbTCO4nNxM0xnvO_Iho4Eks5racyDgaJpZM4L45H2> .

-- Brian E. Granger Associate Professor of Physics and Data Science Cal Poly State University, San Luis Obispo @ellisonbg on Twitter and GitHub [email protected] and [email protected]