Getting rid of Jupyter global

[Carreau]

Main usage of global is for extensions to access things right ?

Idea : pass the relevant local object in ipython_load_extension() which extension should define.

Thoughts ?

[takluyver]

There needs to be some way for users to open a JS console and poke around the JS interfaces. How would we do that without a global of some kind?

[ellisonbg]

Is there a way that we can grab a handle to the things that require has
imported for a page?

I am all for getting rid of the global, but agree with @takluyver about
needing a handle for debugging things

On Thu, Jun 25, 2015 at 11:30 AM, Thomas Kluyver [email protected]
wrote:

There needs to be some way for users to open a JS console and poke around
the JS interfaces. How would we do that without a global of some kind?

—
Reply to this email directly or view it on GitHub
#170 (comment).

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[Carreau]

Well, modules are still available by foo = require('path'), I have no issues having user poking around, but what if you want many notebook per page ? What about many extensions requiring the global IPython ?

We need a way for it to work even without globals, and we can have global injection to be done only if user click a checkbox or set an option. Though it forces extensions and code to be clean of global only, and get convenience of global only in explicit case. e

[ellisonbg]

I should clarify - I am fine completely getting rid of the global - I think
we just want to have some way for users to dig around and get access to the
objects for debugging

On Thu, Jun 25, 2015 at 1:51 PM, Matthias Bussonnier <
[email protected]> wrote:

Well, modules are still available by foo = require('path'), I have no
issues having user poking around, but what if you want many notebook per
page ? What about many extensions requiring the global IPython ?

We need a way for it to work even without globals, and we can have global
injection to be done only if user click a checkbox or set an option. Though
it forces extensions and code to be clean of global only, and get
convenience of global only in explicit case. e

—
Reply to this email directly or view it on GitHub
#170 (comment).

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[takluyver]

The important bit is the instances, which you can't get with require. I don't think poking around should only be possible if you set some special option. And we're still a long way from having multiple notebooks on a page, so we've got time to work out a good solution to the problem that doesn't make the notebook less capable.

[ellisonbg]

Yes, it is definitely the instances. phosphor may help with this - Chris
actually has a very powerful system that takes care of instantiating
objects that implements various interfaces and tracking their lifetimes and
interactions.

On Thu, Jun 25, 2015 at 1:59 PM, Thomas Kluyver [email protected]
wrote:

The important bit is the instances, which you can't get with require. I
don't think poking around should only be possible if you set some special
option. And we're still a long way from having multiple notebooks on a
page, so we've got time to work out a good solution to the problem that
doesn't make the notebook less capable.

—
Reply to this email directly or view it on GitHub
#170 (comment).

Brian E. Granger
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
[email protected] and [email protected]

[Carreau]

The point is not to cripple the notebook, it is to make hard to access the global in places where you should not, like

define(['forget_namespace'],function(){
    // Use global without realizing. 
})

> Yes, it is definitely the instances. phosphor may help with this - Chris
> actually has a very powerful system that takes care of instantiating
> objects that implements various interfaces and tracking their lifetimes and
> interactions.

For that it would be nice to push typescript and notebook rewriting forward... it nice to say that it's a powerful things, it would be nice to use it.

[minrk]

Yup, I think it's just the instances, adn I think it's really just IPython.notebook, the outermost instance, that's needed to be attached to something global. We could attach it directly to window, I suppose. I'm fully in support of removing all of the IPython.Classes, etc. from the IPython namespace, and removing any reference/use of the IPython namespace outside the main.js files.

[Carreau]

keyboard_manager too need to be somewhere. Wether IPython or notebook is top level is the same problem, it is just a global. It would be nice to have something explicit like a function call à la get_ipython()

[takluyver]

But then you need to make the function global, and it needs to be a closure over a reference to IPython or notebook, or something. It doesn't avoid having a global, it just makes it slightly harder to use.

The only way I can think of to avoid making it a global is to attach it to an element on the page, so you have to do e.g. $('#notebook').data('notebook') to get it. That seems inelegant, and unnecessary until we actually have multiple notebooks on a page.

[Carreau]

The problem is that the global IPython and the requirement: require(['base/js/namespace'], function(IPython){}) in the end expose the same thing: IPython. Which make the distinction for users impossible.

$('#notebook').data('notebook') or get_ipython() make it obvious there is a difference. Even injecting the name differently global 250ms after notebook ready would at least prevent user from using it in extensions.

[JamiesHQ]

Can this issue be closed? Any additional steps to take?

[ellisonbg]

I think so, but @Carreau should confirm.

[Carreau]

It's not really addressed it's probably better in JupyterLab, but depending on how long the classic notebook lives I would still like to have a better story for that.

[JamiesHQ]

cc'ing @blink1073 and @gnestor so the work can get added to the appropriate queue

[ellisonbg]

While I remain fine with removing the global, I think it will cause more pain for users and ourselves (debugging) than it is worth. If we do keep this, it should be very low on the backlog of the classic notebook.

[Carreau]

While I remain fine with removing the global, I think it will cause more pain for users and ourselves (debugging) than it is worth. If we do keep this, it should be very low on the backlog of the classic notebook.

But extension that want to be compatible JupyterLab and classic notebook cannot make the assumption that notebook is a global. Passing notebook as a parameter to the extension seem the right thing to do and push for good habits to make the transition easier.

[gnestor]

Not sure what next steps should be, but taking @ellisonbg's advice and marking as backlog and low priority...

[ellisonbg]

@gnestor can comment more, but I think that extensions that need to support both lab/classic will take the approach Grant has been pursuing in thing like jupyter_vega, where it has 1) common JS and 2) wraps that into an nbextension and 3) wraps that into a labextension. In other words, we will still likely have small amounts of impedance mismatching between the APIs.

…

On Tue, Apr 25, 2017 at 11:03 AM, Grant Nestor ***@***.***> wrote: Not sure what next steps should be, but taking @ellisonbg <https://github.com/ellisonbg>'s advice and marking as backlog and low priority... — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#170 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABr0I0mECJ8_DqJGE8DU8UfwKebmJKQks5rzjWKgaJpZM4FLi4W> .

-- 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]

[gnestor]

@ellisonbg I'm happy to comment but I'm not 100% clear on the problem here...