Migrate to pygls v1.0 #484
Conversation
alcarney
force-pushed
the
pygls-1.0
branch
2 times, most recently
from
8b32ecc
to
038f30b
Compare
|
pygls v1.0 is now out and the migration is done, I just need to get an updated version of I'd say this was ready to test if anyone fancies trying this branch out. There is also a migration guide for pygls which you might find useful if you're an extension author. The plan is to include this in the next feature release |
|
Happy holidays! Any ETA on this? Latest jedi-language-server and the new ruff-lsp require pygls 1.0.0. Esbonio and jedi-ls are available for system installation in the Arch repos, and I would like to make a ruff-lsp package for the AUR. |
|
Happy holidays to you too! 😄 Technically the only thing holding this up is a new release of That said, I'd also like to get #514 merged first as I'd rather not force the migration onto @stsewd if I can help it, but we'll see how it goes. |
|
Works for me, backported this PR in the meantime: |
Finally figured out how to run `mypy` as a pre-commit hook in a way that allows `mypy` to resolve imports correctly.
Turns out each module within a namespace requires its own `py.typed` file > For namespace packages (see PEP 420), the py.typed file should be in > the submodules of the namespace, to avoid conflicts and for clarity. > This PEP does not support distributing typing information as part of > module-only distributions or single-file modules within namespace > packages. > The single-file module should be refactored into a package and > indicate that the package supports typing as described above. See: https://peps.python.org/pep-0561/#packaging-type-information
They won't work with the latest `lsp-devtools` anyway...
This is very early and very rough but I think it's worth giving people the heads up that this is coming.pygls, the library thatesboniorelies on for it's language server protocol implementation has released v1.0 with some breaking changes (see openlawlibrary/pygls#273 more details), this PR migratesesbonioto this new version.These changes may or may not affect you, depending on how you use
esbonio.End Users
Apart from dropping Python v3.6 support, there should be no breaking changes in
esbonioIntegrators
As mentioned above Python v3.6 will no longer be supported, and some transitive dependencies will change but everything else (config values, notifications etc) should remain the same.
Extension Authors
There unfortunately, will be breaking changes but they will be due to implementation details from
pyglsleaking through rather than any changes to esbonio's APIs. Hopefully this means the migration is not too painful.A migration guide for pygls is still being worked on, but here's some of the highlights.
pygls.lsp.typesandpygls.lsp.methodsmodules have been removed, all LSP type and method definitions are now provided by the lsprotocol packagepydantic, but withattrsand usingcattrsfor serialization/deserializationWhiletesting will certainly be appreciated,I don't think this PR is quite ready for that as I am already aware of some issues that require further changes upstream inpygls. I am also not expecting this to land for a while yet and intend to make at least one more release based on the old version ofpygls.Pinging some people who probably have an interest in this
@lextm @yaegassy @danwos @haiyangToAI
Let me know if you have any thoughts
Closes #400