Block fetching the settings for a plugin that is disabled.

[afshin]

References

Fixes #7107

As a side-effect of this work, I proposed we remove the concept of deferredExtensions for JupyterLab 2.0 on the weekly call.

Dependency: #7216

Code changes

• Updates logic in index.js to make sure extensions that export a single plugin do not fall through the cracks and respect disabling/deferring.
• The transformation timeout of the setting registry is shortened from 7 seconds to 1 second.
• The setting registry plugin ignores deferredExtensions and disabledExtensions when it preloads the setting registry.
• The setting registry plugin waits until app.restored and then attempts to load the settings for any plugins that did not preload, including deferredExtensions.
• If there is a (1 second) timeout again for a specific plugin's settings and its settings schema has set the jupyter.lab.transform flag to true, there is a console warning that autoStart may have been set to false or that the plugin may be one of the deferredExtensions.

User-facing changes

N/A

Backwards-incompatible changes

N/A

[jupyterlab-dev-mode]

Thanks for making a pull request to JupyterLab!

To try out this branch on binder, follow this link:

[vidartf]

Looks good, one minor comment inline.

While this is clearly a step in the right direction, I also start asking the question about what would happen if a transforming plugin has autostart: false, or is deferred, and is not required by another plugin. Since the transformers are typically (always?) registered in the activate function, I assume they would display the same behavior. I'm happy to leave the decision of whether to punt this or not to @afshin .

[afshin]

I'm not 100% convinced this is the right way to do this at all. Here are some of my concerns:

1. Perhaps the jupyterlab_server settings endpoint should not return any settings for disabled plugins.
2. The isDisabled logic is now being duplicated, once in @jupyterlab/services and once in index.js. Perhaps it belongs in PageConfig.

[afshin]

As for your question about transformers, they happen in the preload of the setting registry. That's populated by the list() method, so it should be okay.

I am conflicted about this approach because perhaps it is legitimate to disable a plugin but still load its preferences and use them.

We need to have a coherent rationale about this. That's why I've left this as a work in progress, because I'd like to raise the issue in our meeting today.

[vidartf]

As for your question about transformers, they happen in the preload of the setting registry. That's populated by the list() method, so it should be okay.

How so? If (deferred or autorun==false) and not plugin_requested, the plugin will not register its transformers, but the list() method will still include that plugin's settings (the server doesn't know the status of the deferral). As a result, the page load will again be delayed by the transformation timeout of 10 seconds, as the registry is waiting for transformers that never appear.

I am conflicted about this approach because perhaps it is legitimate to disable a plugin but still load its preferences and use them.

Sure, let's try to brain storm some alternative solutions in today's call (written proposals also accepted 😉 ).

[afshin]

Yeah I suppose we could add a disabled flag to each plugin returned from the data connector and the setting registry could ignore transform on any disabled plugin. I'm not sure, this all sounds too complex. Perhaps it should be the way it is now or even one layer farther down with the server never even sending a disabled plugin's settings.

[afshin]

I think the Linux Usage failure is legitimate because I'm modifying the index.js files. But I'm not sure. This is still work in progress, regardless.

[afshin]

Okay, I think the reason that this check fails:

python -m jupyterlab.browser_check --core-mode

Is because it pulls PageConfig from the published @jupyterlab/coreutils. If this is the case, then the CI can't pass until we publish a new version of @jupyterlab/coreutils. Perhaps @saulshanabrook @jasongrout @vidartf know if I've understood this problem correctly?

[afshin]

I am unsure what is happening here. The Linux usage test times out so I can't see log output. When I run the individual stages of the Linux Usage manually following along with ci_script.sh in my local environment, it passes.

Does anyone have any ideas how to un-stuck this?

[vidartf]

@afshin Sorry for being slow in reviewing this. This mostly looks good now, but I have some questions below.

[vidartf]

Would it make sense to move this functionality to the services package itself? It seems as if it might have reuse value? That might also formalize it more, as we can add a docstring explaining that active implies that it is not disabled, and not deferred.

[afshin]

I thought about putting it in services, but it seemed very specific to the functionality of the SettingRegistry and it seemed to me that the services package should be completely agnostic about what you're doing with the data being returned from the back-end.

Another place I considered putting this logic was as a query parameter to the back-end, which still remains a possibility (in which case, I'd agree with your suggestion to move this into services).

But for now, this seemed like the most unobtrusive thing to do because it seemed to localize the changes to the actual location of the concern. Do you disagree?

[vidartf]

Just so we're clear: what is the purpose of the code that follows? This comment says what is happening, but not why.

[afshin]

Basically, if a plugin is deferred but not disabled and nobody has chosen to use it, its settings will not be editable by end users. This logic is meant to handle that scenario. It also handles the problem you originally pointed out if a deferred plugin has a transformation that never completes.