Skip to content
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

Use app's HTTP settings, handle feature settings race condition, CI/build updates, lazy server discovery #882

Merged

Conversation

bollwyvl
Copy link
Collaborator

@bollwyvl bollwyvl commented Dec 10, 2022

References

Code changes

  • /
    • resolve and deduplicate yarn.lock: get "one true version" of typescript, prettier, webpack
    • add sourcemaps (we can take these out, but... would be really nice for downstream debugging)
  • .github
    • bump more CI action versions to squash warnings
  • @jupyter-lsp/jupyterlab-lsp
    • initialize LanguageServerManager with app.serviceManager.settingsis being used
    • use these settings for doing API requests and WebSockets
    • handle a race condition for very fast settings loading (no http request) for plugins with a PromiseDelegate
    • update @jupyterlab/* dependencies to match python-level dependency
  • @jupyter-lsp/lsp-ws-connection
    • use webpack 5 for lsp-ws-connection
    • normalize void for handling of promises
    • bumps version
  • jupyter_lsp
    • use importlib(_|.)metadata for entrypoints
    • bumps version
    • defers language server spec discovery until the event loop is ready

User-facing changes

  • hopefully few visible changes

Backwards-incompatible changes

  • python
    • downstreams which interact with jupyter_lsp.LanguageServerManager directly may need to await more things

Chores

  • linted
  • tested
  • documented
  • changelog entry

@github-actions
Copy link

Binder 👈 Launch a binder notebook on branch bollwyvl/jupyterlab-lsp/gh-880-mk2-use-server-http-settings

@bollwyvl bollwyvl changed the title Gh 880 mk2 use server http settings Use server's http settings, handle feature settings race condition, CI/build updates Dec 11, 2022
@bollwyvl bollwyvl changed the title Use server's http settings, handle feature settings race condition, CI/build updates Use app's HTTP settings, handle feature settings race condition, CI/build updates Dec 11, 2022
@bollwyvl bollwyvl changed the title Use app's HTTP settings, handle feature settings race condition, CI/build updates Use app's HTTP settings, handle feature settings race condition, CI/build updates, lazy server discovery Dec 11, 2022
@bollwyvl bollwyvl marked this pull request as ready for review December 11, 2022 22:32
@bollwyvl
Copy link
Collaborator Author

Ha, green!

I can roll back the server lazy loading changes if desired.

@@ -36,5 +36,5 @@ zip_safe = False
python_requires = >=3.7

install_requires =
jupyter_lsp >=1.4.0
jupyter_lsp >=1.6.0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is required, should we consider making a major version bump?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, it's probably worth pulling this part onto a separate PR, and doing some manual reverts.

Also, of note, we might need to be very ginger with ipykernel 6.19.*. as i was seeing some message-related stuff that might confuse our test rig.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's keep going an release 2.0 then. I hope to get to releasing stuff over the break.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to clarify, which of the below:

Some background:

I guess it depends on how semver we're getting: the contract with the frontend doesn't actually change at all, but I am wary of not also testing against the oldest supported serverextension, whereas moving the pin makes it relatively clear.

The manager API does change a bit, to avoid paying for language server discovery. So if someone was overloading the manager, but using the stock routes, that could be an issue.

The listener API does not change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

keep going on this, but instead of bumping to 1.6, bump to 2.0

I was thinking this one. Especially if we could also get #636 in. Otherwise maybe 1.6 is fine.

So if someone was overloading the manager, but using the stock routes, that could be an issue.

Yes. I don't know of anyone who does that. I don't feel strong about this especially since we did not advertise support for overloading it like that.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Especially if we could also get #636 in.

That would be great.

Expounding a little further: should 2.0 be

  • python >=3.8
    • Ipykernel, etc. have already started to move on.
  • jupyter_server >=2.0
    • it's just going to be really messy for a while, but it will be a lot simpler to support

@@ -1,5 +1,6 @@
import * as events from 'events';

import 'setimmediate';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this needed? It looks as not maintained for a while now, and I am not sure where it gets used. Is this due to a setImmediate cal in one of dependencies?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a setImmediate cal in one of dependencies?

Deep in one of the vscode-* ones, and extremely hard to track down (hence the sourcemaps).

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

haha, uses that, too

@krassowski krassowski merged commit 389cc50 into jupyter-lsp:master Dec 18, 2022
@bollwyvl
Copy link
Collaborator Author

Cool, glad to have this one in.

I'll have another look at working the CI assets into the downstream on jupyterlite-lsp...

This was referenced Mar 21, 2023
krassowski added a commit to krassowski/jupyterlab that referenced this pull request Jun 18, 2023
fcollonval pushed a commit to jupyterlab/jupyterlab that referenced this pull request Jun 22, 2023
* Use proper web socket URL, see jupyter-lsp/jupyterlab-lsp#819

Co-authored-by: Author: MikeSem <[email protected]>

* Use app's HTTP settings, cherry-picked from jupyter-lsp/jupyterlab-lsp#882

Co-authored-by: Nicholas Bollweg <[email protected]>

* Support optional `.virtual_documents`

Cherry-picked from jupyter-lsp/jupyterlab-lsp#930

---------

Co-authored-by: Author: MikeSem <[email protected]>
Co-authored-by: Nicholas Bollweg <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use the host application's server connection settings
2 participants