search

jupyter-lsp / jupyterlab-lsp

Coding assistance for JupyterLab (code navigation + hover suggestions + linters + autocompletion + rename) using Language Server Protocol
https://jupyterlab-lsp.readthedocs.io
BSD 3-Clause "New" or "Revised" License
1.81k stars 148 forks source link

Migrate to JupyterLab 2.0 #186

Closed krassowski closed 4 years ago

krassowski commented 4 years ago

We will need to branch off at some time in order to migrate to JupyterLab 2.0 (which will be released soon). It would be good to merge any existing PRs (other than my stale ones) and avoid starting any new substantial work (other than bugfixes), particularly anything touching the JupyterLab internals. Also, the icons system is updated in 2.0 - that's why I did not add a nicer icon so far.

There is a draft migration guide here: https://jupyterlab.readthedocs.io/en/latest/developer/extension_migration.html. If we have time to do this early, we can contribute to making it more complete.

I might have some time this weekend but will rather spend it writing more browser tests so we can have a well-tested transition. @bollwyvl please let me know if you have any other local work related to browser tests that I should wait for.

bollwyvl commented 4 years ago

Good times.

A test I wanted to add for the "one socket" pr was to open ten+ files with the same language... The existing event thing has a hard maximum listener count. Master doesn't have this problem, as it would just keep opening websockets, and won't fall over until you run out of RAM (or sockets, which can happen).

To fix it, I'd have to remove the remaining per-doc .on() calls, which might motivate the diagnostics refactor.

One thing I was mulling over, since we want to get into core: what if we started the 2.0 integration work directly against a fork of jlab? Now would be a swell time to start following the development pattern exactly of what lab is doing (even if we keep doing additional real-browser tests, which I prefer to the puppeteer ones lab has, but that's another story).

I'm pretty slammed at work, but I'll see what I can do.

On Wed, Jan 29, 2020, 14:18 Michał Krassowski notifications@github.com wrote:

We will need to branch off at some time in order to migrate to JupyterLab 2.0 (which will be released soon). It would be good to merge any existing PRs (other than my stale ones) and avoid starting any new substantial work (other than bugfixes), particularly anything touching the JupyterLab internals. Also, the icons system is updated in 2.0 - that's why I did not add a nicer icon so far.

There is a draft migration guide here: https://jupyterlab.readthedocs.io/en/latest/developer/extension_migration.html. If we have time to do this early, we can contribute to making it more complete.

I might have some time this weekend but will rather spend it writing more browser tests so we can have a well-tested transition. @bollwyvl https://github.com/bollwyvl please let me know if you have any other local work related to browser tests that I should wait for.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/krassowski/jupyterlab-lsp/issues/186?email_source=notifications&email_token=AAALCRG55TWKZAITWOE4YI3RAHI7TA5CNFSM4KNKB7KKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4IJUDJSA, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAALCRASNX5OFW3MUNE7MH3RAHI7TANCNFSM4KNKB7KA .

bollwyvl commented 4 years ago

The day has come :tada: !

https://pypi.org/project/jupyterlab/2.0.0/

How do you see this playing out? It might be nice to get #202 in and cut 0.8.0 releases as the final thing for the 1.2.x line, and then concentrate on getting going here. Seems likely the jumper extension will need upgrading: time to move that into this repo?

krassowski commented 4 years ago

We could move it here, but aiming to split it into "jumper-core" and language-specific implementations (don't have to be now, I can do it later!)... just to say it out loud, the UX will might suffer with this move if it would mean that the jumper is no longer installable separately, without lsp - if someone is used to having the jumper without installation of the server extension and a language server, this may be a step back for them. So it would be ideal if it was still possible to install it separately, but even if it is not possible, we may want to roll with the 2.0 being a big breaking release.

krassowski commented 4 years ago

I have small uncommitted (and unfinished) work on foreign extractors that I want to merge into 0.8, but if you have time to work on 2.0 port, I could backport it later as well. After 0.8 release I will create a 0.8.x branch and let's carry on on master. Just one litter comment on #202 (sorry for the delay here) something with a docstring seems odd.

bollwyvl commented 4 years ago

jumper without installation of the server extension and a language server

I'm all for having it remain standalone, separately installable: I'm just suggesting that having its development in this repo (especially if you're thinking about splitting features) would help during the 2.0 transition (otherwise we're blocked here entirely), and future features, a la multiple possible targets, might be easier to co-develop.

I'll have a look at #202: and never worry about keeping me hanging! as long as we're moving forward, whatever the pace, I'm happy.

bollwyvl commented 4 years ago

Made those fixes in #202: i'll watch CI, and if everything seems on the up-and-up, i'll start wading into lab 2.0 as a fork off of that.

in the meantime, some field notes from migrating another extension: aside from the painless phosphor -> lumino, I hit:

some things i want to do over there, that we'll probably want over here:

bollwyvl commented 4 years ago

CI good over on #202!

bollwyvl commented 4 years ago

disable the node build check now

this looks great on test logs: far less noise

get some things into the running sidebar and stoppable there

this worked pretty well, but I have far little observability about the incidental background task i'm starting, and have to press the refresh button. however, i think for language servers, it will be great. clicking on a language server can pop open whatever we want: it will feel good to have per-server config show up there, and be great to be able to stop servers without reloading the browser/notebook server or mucking about with kill.