New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extension breaking after upgrading from 0.35.5 to 1.0.0a8 #6560
Comments
Hi @tugceakin, it sounds like duplicate dependencies. Is your code available in a public repo? |
Hi @blink1073, I created a simplified public repo to reproduce the issue: https://github.com/tugceakin/jupyterlab-dependency-bug I also added updated and previous version of my package.json dependencies to the issue comment. |
Found it! Tokens are meant to be singletons, and your extension was returning Here is a working diff: diff --git a/src/index.ts b/src/index.ts
index 5949fbc..b9479c6 100644
--- a/src/index.ts
+++ b/src/index.ts
@@ -14,7 +14,7 @@ import {
IStateDB
} from '@jupyterlab/coreutils';
-export const layoutExtension: JupyterFrontEndPlugin<ILayoutRestorer> = {
+export const layoutExtension: JupyterFrontEndPlugin<void> = {
id: '@ulab/application-extension:layout',
//id: '@jupyterlab/application:ILayoutRestorer',
@@ -23,8 +23,7 @@ export const layoutExtension: JupyterFrontEndPlugin<ILayoutRestorer> = {
// Doesn't work
requires: [IStateDB, ILabShell, IDocumentManager],
- activate: (app: JupyterFrontEnd, state: IStateDB, shell: ILabShell, docmanager: IDocumentManager) => {//, docmanager: IDocumentManager) => {
-
+ activate: (app: JupyterFrontEnd, state: IStateDB, shell: ILabShell, docmanager: IDocumentManager) => {
const first = app.started;
const registry = app.commands;
const restorer = new LayoutRestorer({ first, registry, state });
@@ -40,10 +39,9 @@ export const layoutExtension: JupyterFrontEndPlugin<ILayoutRestorer> = {
}
// Do things
initLayoutRestorer(null);
- return restorer;
+ return;
},
- autoStart: true,
- provides: ILayoutRestorer
+ autoStart: true
}; |
@afshin do you think this is something we could catch? More than one plugin trying to provide the same token? |
@blink1073 The original submission says:
So I don't think asking them to stop providing the token will work? |
I see that they already do, I missed the deletion of the leading characters. |
One dependency loop (there might be more):
|
Regarding that loop, the relevant question would be if it would be better for the IInspector provider to add its own commands to the file menu. This seems like a reasonable request, as there is no guarantee that all providers of
|
PS: Phosphor does have code for detecting cyclical token dependencies: https://github.com/phosphorjs/phosphor/blob/0d842588195ec7b056db946ae0c55de2ef06886f/packages/application/src/index.ts#L212-L213 |
I opened an issue on the phosphor repo about the cycle check (phosphorjs/phosphor#389), but that should not supersede the discussion in this issue. |
I don't know if we can catch it in JupyterLab, but I think one level up, we could probably check if the extension's return value is identical to another on at the Phosphor level ... but is that sound behavior? We would probably have to special-case it to only identical |
cc @ian-r-rose which previously suggested that duplicate tokens should always overwrite core ones. |
My thinking was, if an extension wants to override a core token, we should respect that and allow it to take precedence. We already do some logic around |
What if there are multiple extensions that want to override the core token? |
Unsure. At that point, I suppose it could be last-write-wins, as documented in the phosphor docs. |
Hm, I wonder if we should somehow let the developer know, maybe in the console by giving a hint that an extension was overridden and should probably be disabled. |
@blink1073 Thank you for looking into the issue! Yes, that's why I'm disabling If I don't disable this extension layout restoration logic could be racy I think. I tried your code and now I'm getting another error: (That's why I have |
@tugceakin Two updates here:
If you can confirm that your code works with the RC, we can close this issue I think, but there was quite a few topics discussed here, so maybe some other TODOs should be moved to separate issues? |
Given the above comment by @vidartf, moving this issue to 1.1. If there is indeed something crucial to 1.0, let's open a new specific issue to fix before 1.0. |
@vidartf @jasongrout Thank you! I'm not seeing call stack error after upgrading to 1.0.0-rc.0 — I haven't tested my extension very thoroughly but everything looks good. |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related discussion. |
In our extension we provide our own layout restorer by disabling the default restorer and activating ours.
The main difference in our custom layout restorer is the use of IDocumentManager to open widgets during restoration process. We built this to save custom layouts in a DB and load them during initialization.
This was working fine in
0.35.x
but it's breaking in 1.0.0a8 withUncaught RangeError: Maximum call stack size exceeded
so I think there is a circular dependency somewhere. I don't get this error if I remove IDocumentManager fromrequires
array. I would love to hear your suggestions if you think this problem could be solved differently.To Reproduce
https://github.com/tugceakin/jupyterlab-dependency-bug
1 - Disable the default restorer:
jupyter labextension disable @jupyterlab/application-extension:layout
2 - Then activate the custom extension (I refactored this to accommodate
app.shell(0.35)
->ILabShell(1.0.0x)
changes) :3 - Install the extension
jupyter labextension install .
4 - Open JupyterLab
Expected behavior
To be able to use IDocumentManager in ILayoutRestorer extension.
Screenshots
Desktop
** Additional Info**
Updated package.json dependencies
Old package.json dependencies
Troubleshoot Output
Browser Output
The text was updated successfully, but these errors were encountered: