Lsp miscellany

[dimbleby]

Description (e.g. "Related to ...", etc.)

Related to #139 (and this pull request is against that branch).

I have:

• allowed pydantic and typeguard versions to go higher. typeguard declares that it follows semantic versioning, so 2.x should be safe. pydantic seems to make breaking changes at minor releases; however 1.8 works just fine so I've allowed 1.7.x and 1.8.x

• tweaked ClientCapabilities.has_capability() along the lines I suggested in Added type checking and update types (LSP-3.15) #139 (comment) ie added a type annotation, and allowed it to return a default value. I've also renamed it to get_capability(), since it handles not only boolean values (eg text_document.completion.completion_item.documentation_format is a list of MarkupKind).

[perrinjerome]

Changing the version constraints to be less strict like this makes a lot of sense to me. I feel that libraries should generally not have version constraints in their setup (or maybe a >= minimal.version when they require a minimal version) and that picking the good version is a problem for applications. When application depends on multiple libraries, if libraries specify exact requirements in their setup.py it can lead to version conflict. For example, if one wants to build an langage server application with a library "example" and pygls, which has pydantic==1.7 in their install_requires , if that "example" library also depends on pydantic and have a install_requires like pydantic==1.8, the installation would be impossible. That's why I believe libraries should not have strict versions in their setup.py. For test requires or docs requires it's not really a problem, but for install requires it can be.

[danixeee]

Agreed with everything you said. Thanks for the help! I will merge it now and apply some suggestions from @perrinjerome.