jupyterlab-lsp: Incompatibility with JupyterLab core npm packages 3.0.10
Description
We use a custom version of JupyterLab which depends on the following dependencies that I upgraded:
Doing that broke the LSP extension in that the check if not uri.startswith(virtual_documents_uri) in “virtual_documents_shadow.py” at line 141 now fails. This is due to an additional “/” that gets inserted in the file URI as per this example:
uri file://c:/XXX/.virtual_documents/1%20Migration%20Guide.ipynb doesn't start with file:///c:/XXX/.virtual_documents
Reproduce
Bump up to the latest version of JupyterLab.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 17 (14 by maintainers)
Commits related to this issue
- Workaround file URI matching issue for now See https://github.com/krassowski/jupyterlab-lsp/issues/595 — committed to jupyter-lsp/jupyterlab-lsp by krassowski 3 years ago
- Workaround file URI matching issue for now See https://github.com/krassowski/jupyterlab-lsp/issues/595 — committed to jupyter-lsp/jupyterlab-lsp by krassowski 3 years ago
Maybe just strip the prefix before preforming the starts with check, whether it is file:// or file:///? Regular expression would be an alternative, but maybe better to avoid it.
I think maybe the latter (making the server side comparison more lax), would be a good idea too in case something like this happens again — according to the issue you identified I get the impression that this kind of url parsing will remain problematic. I’m happy to create a PR to that effect if you want to tell me how you think the comparison should be performed.
I think the troublesome fix went into 1.5.0. It might be difficult to revert to an earlier version since it got a) a security fix label b) already merged and released by JupyterLab core. I was thinking about an upstream fix, or making our server side comparison be more lenient (as a special case for the lack/presence of triple /).